Playground Checkpoint
Design and build a real schema — no auto-grading, just a real attempt.
The Challenge
Six chapters of real DynamoDB, all converging on one real challenge: design GreenMart's actual order-tracking table, the way this whole Act argued it should be designed — starting from the real questions GreenMart needs answered, not from a list of entities.
Open the Playground and build it for real: create a table with a partition key, sort key, and a Global Secondary Index; store a customer's profile and their orders together as one item collection; refuse a duplicate write with a conditional check; and answer two genuinely different questions — "everything for this customer" and "every shipped order, across every customer" — each as a cheap, targeted request.
What Your Order-Tracking Table Needs
- One table (CreateTable) with a partition key, a sort key, and a Global Secondary Index keyed on a status-like attribute — the same shape single-table design and secondary indexes chapter built.
- A customer profile item and at least two order items sharing the same partition key, distinguished by sort key prefixes (e.g. PROFILE, ORDER#...) — a real item collection, not separate tables.
- One PutItem guarded with { condition: "attribute_not_exists" } that would overwrite an item that already exists — including a second attempt that should fail, on purpose, because the item's already there.
- One Query on the base table's partition key that returns the whole item collection — the profile and every order — in a single request.
- One Query against the Global Secondary Index that answers a genuinely different question (e.g. every order with a given status, across every customer) without a Scan.
Stuck? A Few Hints
- Reread single-table design's own two code examples — the item collection and the GSI query — this checkpoint reuses the exact same shape, just against your own keys.
- CreateTable's globalSecondaryIndexes needs its own partitionKey (and optionally sortKey) — it doesn't have to match the base table's.
- The conditional PutItem's second attempt returning an error is the checkpoint working correctly, not a bug in your script — that's exactly what a conditional write is supposed to do.
Ready to Build It?
Opens the Playground, right in your browser — nothing to install.
Every command should return a real result — a created table, a put item, or a list of matched items. The second conditional PutItem on an already-existing key should come back as an error ("Conditional check failed..."), not succeed — that's the checkpoint working correctly, not a sign something went wrong.
Before You Move On
One table, three entity types sharing an item collection, a conditional write that actually enforces a promise, and two genuinely different questions answered cheaply — a Query on the base table, a Query on a GSI, neither one a Scan. That's the whole Act, in one script: design the questions first, and let the table's shape follow from them.