Write-back cache for high-frequency counters
Design the caching strategy for a write-heavy counter system: per-post view/like counts for a content platform with 1M writes/sec (increments) but reads that tolerate slight staleness. Write-through to the database on every increment would overwhelm it. Design a write-back / write-behind cache that absorbs increments in memory and flushes aggregates to durable storage, and address the hard parts: what happens to in-memory increments if a cache node crashes before flush, how you avoid losing or double-counting, and how reads see a coherent value.
What a strong answer looks like
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.
Clarify5:00 left
Estimate5:00 planned
Design15:00 planned
Deep dive12:00 planned
Failure8:00 planned
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.