fig. SSystem design
Bengaluru--:-- IST
How systems hold up, drawn out.
A working notebook: each concept as a drawing you can play and step through, the trade-off it costs, and where it carries real traffic in the projects I've shipped.
fig. S.1concept atlas
Sixteen ideas, each with a bill.
- Scale · 4
- Data · 4
- Async & real-time · 2
- Resilience · 3
- Security · 1
- Delivery & ops · 2
Caching (cache-aside)
Keep hot, expensive-to-compute answers in memory next to the app, and only fall through to the database on a miss.
The answer is already in memory.
How it works
- 01Read: check the cache; on a hit return it, on a miss query the database and write the result back with a TTL.
- 02Write: update the database first, then delete the cache key - deleting is safer than overwriting under concurrent writers.
- 03TTLs bound staleness; jittered TTLs and request coalescing stop a stampede when a hot key expires.
The trade-off
There are now two copies of the truth. Every cache is a promise about how stale you are willing to be - make it explicit per key.
Reach for it when
- Read-heavy endpoints
- The same query runs thousands of times
- p95 is dominated by the database
fig. S.2blueprints
The same ideas, in production.
Every shipped project drawn in one notation. Replay a request, inspect a component, or turn on a concept lens to see which parts of the system practise it.
One deployable API split into 28 domain modules with hard boundaries, a PWA client that caches aggressively and survives offline, and Redis doing triple duty as cache, pub/sub and job broker in front of PostgreSQL.
- Client
- Cache
- Edge / proxy
- Service
- Worker
- Database
- Platform
- async
Flow · Read · cache hit
Opening a workspace: two caches stand between the click and the database.
fig. S.3concept × project
Right-sized, not over-built.
A conference site does not need a message broker; a SaaS workspace does. The empty cells are decisions too.
Hover a cell to see which part of each system does the work.