MVCC garbage collection
An MVCC database (think Postgres-style) is accumulating dead row versions: tables and indexes keep growing far beyond the live data, sequential scans get slower, and the autovacuum/GC process can't keep up. Investigation shows occasional long-running read transactions (analytics queries, a stuck connection holding a snapshot) that run for tens of minutes. Design the version garbage-collection / vacuum subsystem and explain precisely why long-running readers cause unbounded bloat and how you bound it without breaking snapshot reads.
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:30 left
Estimate5:30 planned
Design16:30 planned
Deep dive13:30 planned
Failure9: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.