A team is about to hand-build and maintain three separate index tables over a dataset stored in DynamoDB, to support queries by three different non-key attributes. What native DynamoDB feature should they evaluate first before committing to hand-rolled index tables, and under what circumstances would hand-rolled index tables still be the right call despite that feature existing?

## What a GSI already does for you The first move here is recognizing that DynamoDB — unlike the classic Azure Table Storage case the index table pattern was originally documented against — actually does offer a native answer to 'I need to query by an attribute that isn't my primary key': the Global Secondary Index (GSI). A GSI is a second, DynamoDB-managed index on the same table with its own partition key and optional sort key, drawn from attributes already present on the base items, plus an optional projection of which attributes get copied into it. Once defined, DynamoDB itself is responsible for propagating every base-table write into the GSI — the application writes to the base table exactly once, using ordinary `PutItem/UpdateItem/DeleteItem` calls, and DynamoDB asynchronously derives and maintains the GSI's contents behind the scenes. A table can have up to 20 GSIs (a service-level default that can, in some accounts, be raised), each independently capacity-provisioned (or covered by on-demand billing). ## Why it fits this scenario For the scenario described — three non-key attributes needing lookup support — this is close to a textbook case for GSIs over hand-rolled index tables, and the reasoning is almost entirely about what you get to delete from your own responsibility list: - No application code writes to the index. - There's no dual-write logic, no transactional-scope puzzle, no outbox pattern, no reconciliation job. - None of the failure modes discussed earlier around orphaned or dangling index entries caused by a crash between two independent writes — DynamoDB's internal replication to the GSI is atomic with respect to the base write from the application's point of view (the base write either succeeds, in which case propagation to the GSI is DynamoDB's guaranteed job, or it doesn't happen at all). The team gets three query paths essentially for the cost of three GSI definitions and their provisioned/on-demand capacity, not three hand-built subsystems. ## When hand-rolling still wins — consistency That said, GSIs are not a strict superset of what a hand-rolled index table can do, and there are specific, real circumstances where the hand-rolled version is still the better engineering call. The most commonly cited one is consistency: DynamoDB GSIs are inherently eventually consistent — there is no way to request a strongly consistent read against a GSI, unlike the base table or a Local Secondary Index, which do support strongly consistent reads. If a query path needs guaranteed read-your-own-writes behavior immediately after a write (a security-sensitive uniqueness check on signup, for instance, where you cannot tolerate a race where a duplicate email briefly evades detection), a GSI's propagation lag — typically sub-second but not bounded or eliminable — may be unacceptable, and a hand-rolled index table maintained via a transactional write into the same partition as the base item can provide the stronger guarantee a GSI structurally cannot. ## When hand-rolling still wins — key complexity Second is key complexity: a GSI's key must be drawn from actual item attributes (with limited support for sparse indexing based on attribute presence), whereas a hand-rolled index table's key can be an arbitrary computed value — a normalized/lowercased email, a composite bucket derived from multiple fields with custom business logic, a value that depends on external state — anything the application can compute at write time. If the index key isn't a simple projection of existing attributes, a GSI can't express it and a hand-rolled table (or a hand-rolled attribute the application computes and stores on the item specifically so a GSI can key off it) becomes necessary. ## When hand-rolling still wins — scale and isolation Third is scale and isolation limits: - hitting the per-table GSI cap; - needing the index data physically isolated in a different table, account, or region for independent scaling, security boundary, or cost-allocation reasons; - or needing the index consumed by an entirely separate service with its own access pattern that shouldn't share the base table's throughput budget. All push toward a separately maintained index table, potentially fed by DynamoDB Streams rather than application dual-writes, which is itself a hybrid: DynamoDB-native change capture doing the propagation work, but landing in a hand-rolled destination table. ## The principle to carry The general principle a principal-level engineer should carry into this decision is: prefer the native secondary-index mechanism whenever the store offers one and its consistency/key/scale model fits the requirement, and reserve the hand-rolled index table pattern — with its associated write-amplification, consistency-strategy, and failure-mode costs covered elsewhere — for the store that has no native equivalent (Azure Table Storage, many key-value caches) or for the specific requirement a native index can't satisfy. Building three hand-rolled index tables on a store that already offers GSIs, without first ruling out GSIs on their merits, is a design smell worth pushing back on in review.