Capacity Modes Interview Questions

An RCU covers one strongly consistent read of up to 4 KB per second (two eventually consistent reads). A WCU covers one write of up to 1 KB per second. Larger items consume more units, which is why item size is a capacity decision, not only a modeling one.

They cost half of strongly consistent reads for the same item size, so you get more read throughput per dollar. You may see slightly stale data. Use strong consistency only on paths that must read the write they just issued.

You pay per request and DynamoDB scales throughput automatically up to account and partition limits. There is no provisioned RCU/WCU to set on the table. It fits spiky or new workloads where you would otherwise guess wrong and throttle or overpay.

You (or auto scaling) set RCUs and WCUs the table can sustain. It is usually cheaper for steady, predictable traffic. Set it too low and clients see throttling; too high and you pay for idle units all month.

ProvisionedThroughputExceededException or HTTP 400/429 depending on the SDK, while CloudWatch ThrottledRequests rise. The table may still have unused aggregate capacity if one partition is hot. Clients should backoff; hammering the same key makes it worse.

Scan reads every item in the segment and bills for that read set; FilterExpression does not refund those RCUs. Query only reads matching PK (and SK) items. Capacity incidents that start after someone “just scans for the report” are common.

Unused provisioned throughput can accumulate for short bursts above the set RCUs/WCUs. Bursts are not a plan for a sustained launch spike. Once unused credits are gone, you throttle at the provisioned number.

A scaling policy tracks consumed capacity and raises or lowers provisioned RCUs/WCUs toward a target utilization. Scale-out is faster than scale-in, and there are cooldowns. Auto scaling cannot fix a single hot key; it only moves the table-level ceiling.

Index writes and Query/Scan on the GSI use the GSI’s on-demand or provisioned units. You can throttle an index while the table still accepts PutItem. Capacity planning that ignores GSIs undercounts production write cost.

Round item size up to the next KB. A 1.2 KB write costs 2 WCUs; a 2.1 KB write costs 3. Transactions and some operations multiply further. Measuring with consumed-capacity in the API beats napkin math once attributes vary.

Move to provisioned when traffic is stable enough that reserved-like efficiency beats per-request pricing; move to on-demand when spikes are large and unpredictable. Switch is an update, not instant everywhere—test in staging and watch throttles across the change window.

TransactWriteItems typically consume two WCUs per 1 KB per item, and TransactGetItems consume extra RCUs. A 10-item transaction is not ten cheap Puts. Capacity dashboards that ignore transactional paths will look “fine” until checkout week.

ConsumedRead/WriteCapacityUnits, Provisioned*, ThrottledRequests, UserErrors, and SystemErrors. UserErrors often mean validation or missing keys; throttles mean throughput or hot partitions. Graphing only Latency hides which of those you have.

On-demand is not infinite: AWS enforces per-table and per-account ceilings that you can raise via quota tickets. A new table also has a scaling ramp. Load tests that assume unlimited on-demand often stall at the default account cap.

Load-test realistic keys, pre-warm or switch to on-demand ahead of the event, raise quotas, and scale GSIs too. Keep a cache in front of celebrity items. Changing provisioned numbers minutes after the spike starts is already too late for the first p99 hit.

Throughput is per partition. One hot PK uses only a slice of the table’s WCUs. Contributor Insights plus throttles-with-headroom is the signature. The fix is key design or caching, not another zero on provisioned writes.

Export to S3 or Query a replica/GSI dedicated to reports, with its own throttling budget. Parallel Scan on the live table steals RCUs from the product. If the job must hit production, run it off-peak with RateLimited scans and a kill switch.

You can pre-configure on-demand tables for a higher starting throughput so the first traffic cliff does not sit on the auto-ramp. Use it before launches, migrations, or seasonal peaks. It is not a substitute for even partition keys.

Steady provisioned tables can be cheaper with reservations; spiky tables should stay on-demand even if someone wants a reservation for “discounts.” Mixing modes without a traffic model usually locks you into the wrong bill. Revisit after a month of Consumed* metrics, not on day one.

Use a dedicated table with production-like item sizes and key cardinality, the same GSIs, and the same SDK retries. Never flood prod with synthetic PK=test. Compare throttles, p99, and cost; a test that only looks at HTTP 200 is incomplete.