DynamoDB Keys, Global Tables, and DAX
Key Takeaways
- A DynamoDB primary key is a partition key alone or a partition key plus sort key; the partition key hashes to a physical partition, and items that share a partition key are stored together in sort-key order.
- A global secondary index can use different keys and has its own throughput (default quota 20 per table); a local secondary index must reuse the table’s partition key, is limited to 5 per table, shares table capacity, and caps each item collection at 10 GB.
- On-demand capacity is the default and recommended mode for most tables; provisioned mode plus Application Auto Scaling fits steady, predictable rates, and GSIs need their own scaling policies.
- DynamoDB global tables replicate across Regions; TransactWriteItems and TransactGetItems provide ACID behavior only in the Region where the API is invoked, not as a single atomic unit across replica Regions.
- DynamoDB Accelerator caches eventually consistent reads down to microseconds; it is a poor fit for strongly consistent reads, and writes that land on other global table replicas bypass the local DAX cache.
Why DynamoDB is a different exam conversation than Aurora
Amazon DynamoDB is a serverless NoSQL key-value and document store. AWS’s database decision guide lists it for session stores, shopping carts, and internet-scale request rates with single-digit millisecond performance. Northwind Payments still posts the card ledger on Aurora. The session that holds a shopper’s device token, risk cookie, and short-lived 3-D Secure state is a different access pattern: huge cardinality, known lookups by session identifier, no joins, and a need to run active-active in more than one Region. That is DynamoDB, optionally with DynamoDB Accelerator (DAX) in front of hot keys.
Independent SAP-C02 study material by OpenExamPrep does not treat DynamoDB as “the AWS database.” It is the engine you pick when the stem’s keys and access patterns match what DynamoDB can query efficiently.
Tables, items, attributes, and primary keys
A table holds items. An item is a set of attributes. Other than the primary key, the table is schemaless: items can carry different attributes. Nested attributes can go 32 levels deep. Primary key attributes must be scalar string, number, or binary.
DynamoDB supports two primary key shapes:
| Key shape | Attributes | How storage works | What you can query efficiently |
|---|---|---|---|
| Partition key only (simple primary key) | One hash attribute | The partition key value is hashed to a physical partition; values must be unique | GetItem / Query by that key |
| Partition key and sort key (composite primary key) | Hash attribute plus range attribute | Same hash to a partition; items that share the partition key sit together sorted by sort key | All items for one partition key, or a sort-key range inside that partition |
Northwind’s session table uses SessionId as the partition key. A ledger-style activity table might use MerchantId as the partition key and EventTimestamp as the sort key so one query returns that merchant’s events in time order. Hot partitions happen when one key (a celebrity merchant, a single “GLOBAL” token) absorbs most traffic. Spread keys; do not use a low-cardinality status flag as the only partition key.
Global secondary indexes and local secondary indexes
A secondary index lets you query with an alternate key. DynamoDB maintains indexes as you write the base table. You choose a projection: keys only, include listed attributes, or all attributes. Fetching non-projected attributes from a local secondary index (LSI) query requires an extra base-table read.
| Property | Global secondary index (GSI) | Local secondary index (LSI) |
|---|---|---|
| Keys | Partition key and optional sort key can differ from the table | Same partition key as the table, different sort key |
| Scope | Queries can span all partitions | Scoped to one base-table partition key value |
| Throughput | Own read/write capacity (provisioned or on-demand) | Shares the table’s capacity |
| Size | No LSI-style item-collection cap | Every item collection (table + LSIs for one partition key) cannot exceed 10 GB |
| Quota | Default 20 GSIs per table | 5 LSIs per table |
| When you create them | Can add after the table exists | Must be defined at table creation |
If Northwind must look up sessions by MerchantId when the table’s partition key is SessionId, that is a GSI (MerchantId as the index partition key, perhaps ExpiresAt as the sort key). An LSI cannot change the partition key. If the team already queries SessionId + CreatedAt and also wants SessionId + ExpiresAt without a new partition key, an LSI can fit—until a popular merchant’s item collection approaches 10 GB.
Trap: creating a GSI on a provisioned table and forgetting that the GSI has separate capacity. AWS recommends applying the same Application Auto Scaling settings to GSIs. While a new GSI backfills, auto scaling is not in effect; you manage capacity until the index is active. You cannot run transactions against indexes.
On-demand versus provisioned capacity
A table’s throughput mode decides both scaling behavior and how you pay.
On-demand is the default and recommended option for most workloads. You do not pick read capacity units or write capacity units in advance. DynamoDB scales to the request rate and you pay per request. It fits Northwind’s session table: quiet nights, spikes on shopping holidays, and no desire to tune utilization alarms.
Provisioned mode makes you specify reads and writes per second. You pay for provisioned hours, not consumed requests. Use it when traffic is steady and predictable and you want a hard ceiling for cost governance. DynamoDB auto scaling uses AWS Application Auto Scaling to move provisioned capacity toward a target utilization between a min and max you set. Scale read and write separately. Scale each GSI too.
Switching modes is a design decision, not a hidden default. Spiky global session traffic almost always stays on-demand. A bounded internal rate-limit table might be provisioned.
Global Tables
DynamoDB global tables give you a multi-Region table with replica tables that DynamoDB keeps synchronized. Session state created in Virginia can be read in Ireland without you building a replication pipeline. Current (2019.11.21) global tables synchronize GSI definitions, write auto scaling, capacity mode, key schema, server-side encryption type, and time to live, among other write-path settings. Read capacity and some replica-local settings remain replica-specific.
Replication consumes write capacity. On provisioned replicas, application writes plus replicated writes can throttle if you sized only for local traffic. On-demand replicas adjust automatically; write capacity is synchronized across replicas.
Amazon DynamoDB Accelerator in this topology has a sharp edge: writes to a replica bypass DAX and update DynamoDB directly, so a DAX cluster in front of another Region’s replica can serve stale items until time to live (TTL) on the cache expires. Do not promise a global, immediately coherent DAX.
For Northwind, Global Tables are the session system of record across Regions. DAX is an optional Regional accelerator for eventually consistent hot reads (a flash sale on one ProductId key), not a second source of truth.
DynamoDB Streams
DynamoDB Streams records item-level changes in near-real time, in order per item, for up to 24 hours. Enabling a stream does not slow the table. You choose StreamViewType: KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, or NEW_AND_OLD_IMAGES. You cannot edit the view type in place; disable and recreate the stream (a new ARN). No more than two concurrent readers should hit the same shard.
A classic Professional pattern: stream session invalidations into AWS Lambda, which then deletes a cache entry or writes an audit row. Streams are also how many teams feed Amazon OpenSearch Service or analytics—without pretending OpenSearch is the session store. After a transaction, stream records for that transaction can appear at different times and interleave with other writes; stream consumers must not assume cross-item transactional atomicity.
Time to Live on items still emits stream records when DynamoDB expires data, which matters if Northwind’s sessions vanish automatically after 24 hours and fraud wants an “expired” event.
Transactions: Regional ACID, not a religion
TransactWriteItems groups up to 100 write actions (Put, Update, Delete, ConditionCheck) on up to 100 distinct items in one or more tables in the same account and Region. Aggregate item size cannot exceed 4 MB. Either all actions commit or none do—unlike BatchWriteItem, which can partially succeed. You cannot target the same item twice in one transaction. An optional client request token makes the write idempotent for 10 minutes.
TransactGetItems is the matching atomic read (also 100 items / 4 MB). DynamoDB performs two underlying reads or writes per item (prepare and commit), which you must size for even when a condition fails. Default SDK retries on in-progress conflicts consume still more capacity.
With global tables, transactions are ACID only in the Region where you invoke the API. Writes replicate after they commit locally. Another Region can observe a partial transaction while replication is in flight. If Northwind must debit a session-spend counter and insert a risk flag together, run TransactWriteItems in one Region. Do not claim a single DynamoDB transaction covers Virginia and Ireland.
DAX supports both transactional APIs: writes go through to DynamoDB and DAX then refreshes via TransactGetItems (extra read capacity). TransactGetItems through DAX is not cached, like other strongly consistent reads.
Single-table versus multi-table is a judgment
Some teams put sessions, device fingerprints, and idempotency records in one table with composite keys (PK = SESSION#id, SK = METADATA versus SK = EVENT#timestamp) and GSIs for alternate access. That can cut round trips and keep one capacity pool. It also concentrates blast radius, backup scope, and IAM.
Multiple tables fit when entities differ in TTL, encryption, compliance, on-demand versus provisioned mode, or who may Scan. SAP-C02 is not testing whether you memorized a blog that says “always single-table.” It is testing whether you modeled the query, avoided hot keys, sized GSIs, and isolated a PCI-sensitive table from a clickstream table when the stem demanded isolation.
Use single-table design when access patterns are known and stable and items naturally share a partition-key namespace. Use multi-table when capacity, security, or lifecycle diverge. Mixing both in one company is normal.
Session-store scenario
Northwind’s edge in three Regions writes SessionId items with a 24-hour TTL. A GSI on MerchantId supports “all live sessions for this merchant.” Global Tables keep the three Regions in play. On-demand mode absorbs Black Friday. DAX sits only in the Region that hosts a hot product-detail read path, with a short cache TTL. Lambda on Streams pushes new sessions to a fraud feature store. Authorization money movement stays on Aurora. That split is the Professional answer: purpose-built, not one engine for sessions and settlements.
DynamoDB traps
- Using an LSI to change the partition key.
- Ignoring the 10 GB item-collection limit.
- Provisioning the table and leaving GSIs unscaled.
- Believing DynamoDB transactions are atomic across Global Table Regions.
- Putting DAX in front of a workload that requires strongly consistent reads.
- Treating DAX as globally coherent with Global Tables.
- Declaring single-table design mandatory.
- Using DynamoDB Streams as a multi-week audit archive (retention is 24 hours).
Northwind Payments needs a multi-Region session store: millions of short-lived items, lookups by session identifier, single-digit millisecond reads, and active replicas in more than one AWS Region. The card ledger remains on Aurora. Which design matches DynamoDB’s documented strengths for this access pattern?
The sessions table uses SessionId as the partition key. Product wants an efficient query for all sessions of one MerchantId. Which index choice matches DynamoDB’s GSI and LSI rules?
Northwind must update a session spend counter and insert a related risk flag as one all-or-nothing DynamoDB operation. Replicas of the same global table exist in US East (Ohio) and Europe (Ireland). Which statement matches DynamoDB transactions with global tables?