System Design Deep Dives

Curious if your experience matches ours.

Three questions to ask in every design review: 1. What happens if this input is malicious? 2. Who can call this, and how do we know? 3. What's the blast radius if this component is compromised? Takes 10 minutes and catches a lot.

For new grad interviews, is it enough to cover the API, DB schema and hashing? Or do they expect caching, sharding etc.?

1. Context and problem (why now?) 2. Goals and non-goals 3. Proposed design 4. Alternatives considered (at least 2) 5. Failure modes and rollout plan 6. Open questions

We use a polling relay today (every 2s, SKIP LOCKED). Works fine at our scale but people keep suggesting Debezium. At what point is CDC worth the operational overhead?

High level: 1. Picked tenant_id as the shard key (every query already had it) 2. Built a routing layer in the app: tenant → shard lookup cached in memory 3. Logical replication to copy each tenant group to its new shard 4. Dual-read verification for a week (compare results, alert on mismatch) 5. Cut over tenant groups

Let's talk architecture the way it actually works in production: tradeoffs, failure modes, migrations, costs. Interview prep is welcome, but grounded in reality. First thread: what's the most interesting design decision you made (or regret) in the last year?