config
Feature Flags
Flag values per environment, read one at a time or all at once.
The first table where a sort key earns its keep. ENV#<env> gathers every flag for an environment into one partition, and FLAG#<key> identifies one within it - so the same table answers both 'what is this flag set to' and 'what is every flag set to', with no index involved.
The model
Flag
One flag's value in one environment.
- pk
- ENV#<env>
- sk
- FLAG#<key>
Attributes: value (S), type (S), updatedBy (S)
Access patterns
- QueryRead an environment's flags
Every flag for one environment, in one read.
- GetItemRead one flag
One flag's value in one environment.
Design notes
One key shape, two access patternswhy
The partition key is the environment rather than the flag, because the read that matters most is 'every flag for this environment'. Keying by flag instead would make the point lookup just as cheap and the collection read a Scan.
Environments cannot read each otherwhy
A Query for ENV#prod cannot return a staging flag, because the partition key is part of the condition rather than a filter applied afterwards. That is isolation of data, not of throughput - three small environments will sit in the same physical partition, and keying by environment does nothing to spread load. Assuming otherwise is how hot partitions get built.
Values are stored as stringstrade-off
Every value is an S with a type attribute beside it, rather than a native N or BOOL. It keeps one shape for a heterogeneous set and moves parsing to the reader, which is the usual trade for a config table that has to hold anything.
Taught in the course
- The key is the address - GetItem needs the whole primary key: partition and sort.
- One query, a whole collection - Items that share a partition key are read together in one Query.
Every flag for one environment, in one read.
Run an operation to see the raw engine response.
The in-browser engine is a preview build. Transactions, vector search, streams, tags and TTL are among the operations it doesn't implement yet.