Minimal viable KV (spot the SPOF)
First pass — the smallest thing that stores and returns a value durably, before adding anything for latency.
client → 1 LB → app ×4 → sharded db (RF 3, quorum). The write path is correct: acked writes are on a majority, so RPO 0 holds. No cache yet — every read hits the shards.
Two things I know are missing and would add next, in order:
- The single LB is a SPOF — a second LB is the obvious first hardening step, since everything behind it already survives an AZ loss.
- A cache-aside tier for the 90%-cacheable reads, to hit the 50 ms read p99 without over-scaling the shards.
Leaving it stripped-down on purpose — easier to argue about what each addition buys.
6 Comments
Sign in to join the discussion.
- Null Pointer@null_pointer
Yep, second LB is v2, cache is v3. Wanted the durable baseline on record first.
- Write Amp@write_amp
Honest baseline. Everything behind the LB survives an AZ loss and then the LB doesn't — classic.
- Arjun Rao@arjun_rao
Single LB kills the 99.95% SLA on its own — good that you flagged it as the v2 fix instead of hiding it.
- Null Pointer@null_pointer
Yep, fixing the LB is v2. Wanted the baseline on record first.
- Raft Raccoon@raft_raccoon
Everything *behind* the LB survives an AZ loss and then the LB doesn't — classic. Good that you called it out instead of hiding it.
- Latency Larry@latency_larry
The one LB is the whole ballgame for the availability SLA — 99.95% with a single front door is basically impossible, one reboot blows your error budget. Bump it to ×2 and this is solid.