A Serverless Read Path That Survives a Cold Cache

Requirements

What must be true — the how is yours.

1. R1 Reads are served from the cache when it is warm and from DynamoDB when it is not, without the caller being able to tell which — except in latency. rehearsed by D1
2. R2 A write makes the stale cached value unreachable; no reader sees the old value after the write is acknowledged. rehearsed by D3
3. R3 Many concurrent misses on the same key do not turn into many concurrent reads of the store. rehearsed by D2
4. R4 A throttled or unavailable dependency degrades the response deliberately rather than surfacing as a 502. rehearsed by D4 · D5

Technical guidance

• ▸Measure cold and warm invocations separately; averaging them hides the only number anybody complains about.
• ▸Decide your partition key from the access pattern, not from the entity.
• ▸The cache is not a database: everything in it must be reconstructible and safe to lose.

Definition of done

All of them, or it isn't shipped.

• ○ You can state both numbers and say where the cold time went: init, connection setup, or the first store read. — not recorded yet D1
• ○ The store sees far fewer reads than the burst had requests, and you can say what limited them. — not recorded yet D2
• ○ The reader gets the new value; no window returns the old one after the write was acknowledged. — not recorded yet D3
• ○ The endpoint keeps answering from DynamoDB at higher latency, logs the degradation once rather than per request, and recovers without a deploy. — not recorded yet D4
• ○ Throttling is retried with backoff where it makes sense and surfaces as a deliberate status where it does not — never a raw 502. — not recorded yet D5
• ○ Infrastructure is declared as code and the whole stack comes up from a clean clone with one command. — not recorded yet

nothing recorded yet — running the drills fills these in