Cruxly › System design › Running the Design Interview

Deep Dives and Trade-offs

break your own design before the interviewer does

The last fifteen minutes decide your level. The interviewer will pick a component and push. If you get there first — naming your design's weakest point and fixing it — you are running the interview instead of surviving it.

Choose the dive yourself

:::warn Do not say "what would you like to dig into?" That hands over the one chance you have to demonstrate judgement — and it is the single most common way to end a strong sketch on a flat note. :::

Say this instead:

"Three things worry me here: the hot partition on active conversations, exactly-once delivery when a client retries, and what a user sees during a shard failover. The hot partition is the most likely to actually break, so I'll start there — unless you'd rather go elsewhere."

You have now demonstrated that you can rank risks, which is most of what senior design assessment actually is.
And you still deferred at the end, so nothing is lost if they want something else.

:::key Pick where your own numbers are least comfortable

If writes were 50k/s and you waved at partitioning, that is the dive.
Choosing something you have pre-rehearsed, which nothing in your design actually stresses, reads as avoidance — and interviewers have seen it many times.

:::

Trade-offs: name the cost, not just the benefit

Every candidate can say what a cache buys.
The distinguishing move is saying what it costs and how you'd know it had gone wrong.

The four beats, in order. Stopping after the first is the single most common way to sound junior while saying something technically true.

Worked example — a read-through cache:

"At a 99%+ hit rate it cuts p99 from 80 ms to about 5 ms. It costs me staleness — a profile edit is invisible for up to the TTL — and a thundering herd when a hot key expires and a thousand requests miss at once. I'd detect the first only from a user report, which is bad, so I'd invalidate on write rather than rely on TTL. For the second: single-flight on misses, or serve the stale value while one request refreshes it. I still accept a sub-second window where a reader can repopulate a stale value after an invalidation."

And an async write path:

"Writes via a queue absorb the spike and keep p99 flat. They cost me read-your-own-writes — the user posts and doesn't see it. I'd fix the *perception by rendering optimistically on the client and reconciling, rather than making the write synchronous again."*

The dives that come up most

Dive	Detect it as	The fix
Hot partition	"One partition's write latency climbing while the others are flat"	Sub-partition the key, cache just the hot ones, or handle the outlier differently entirely
Duplicate processing	Networks retry — at-least-once is the default	Client-generated ID + uniqueness constraint or dedupe table, with a stated window
Thundering herd	A popular key expires, every request hits the database at once	Single-flight lock, serve-stale-while-revalidating, or early refresh for one hot key; jittered TTLs when many keys would expire together
Cache invalidation	TTL races, or write-through slows every write	Pick one, and say why the failure mode you kept is acceptable for this data
Backpressure	Queue grows faster than consumers drain it	A policy chosen before it happens — shed load, drop low-value work, or block producers

:::warn "Add more consumers" is not a backpressure policy Not if the bottleneck is downstream of them — more consumers just means more concurrent pressure on the thing that was already the constraint. :::

:::key The one line to remember for hot partitions "I'd see it as one partition's write latency climbing while the others stay flat." Detection comes first, before any fix — say it in that order. :::

Consistency, said precisely

Vague consistency talk is the most common way to lose credibility late in the interview.
Be specific about which guarantee and who notices.

The bottom sentence — window plus who notices — outranks naming any position on the spectrum by itself.

Strong — every read sees the latest committed write. Costs a coordinated write path and cross-region latency. You need it for balances, inventory and seat booking.
Read-your-own-writes — you see your own changes; others may lag. Usually achievable by pinning a user's reads to the primary briefly after their write. This is what people actually mean by "it feels broken otherwise".
Eventual — replicas converge, with a window. Fine for follower counts, view counts, feeds.

Then name the window and who notices: "followers see the post within about two seconds; the author sees it immediately because I pin their reads to the primary for five seconds after a write." That single sentence is worth more than any amount of CAP-theorem recitation.
And CAP, if you invoke it at all: a network partition is not a hypothetical, it is a Tuesday. The real question is what your system does during one — refuse writes, or accept them and reconcile? Answer that.

When you do not know

You will be pushed past the edge of what you know. There are two responses and only one of them works.
Do not bluff. Interviewers push precisely because they want to find the edge, and a confident wrong answer is much worse than a boundary honestly drawn.
Instead, reason from what you do know: "I haven't implemented a consensus protocol, so I'd be guessing at the internals. What I do know is what it gives me — a single agreed value across replicas with a majority quorum — and what it costs, which is a round trip per decision and unavailability if I lose the majority. For this system I'd use it for leader election but not on the message write path, because that round trip would blow the latency budget."
That answer contains an admission and is still the strongest thing you could have said, because it demonstrates you can use a component correctly without having built one.

How to say it in the interview

"The weakest part of this design is the conversation shard — a very active group makes one partition hot. Let me work through that unless you'd rather dig somewhere else."

Checklist

Named the three weakest points and ranked them before being asked
Chose the dive where your own numbers were least comfortable
Stated cost and mitigation for every benefit claimed
Said how you would detect each failure, not just fix it
Made retries safe with a client-generated idempotency key
Named the consistency guarantee, the staleness window, and who notices
Drew a clear boundary instead of bluffing when pushed past it

Practice this interactively