BASIC for system design interviews
System design interviews punish premature architecture.
The weak move is familiar:
- mention Kafka early
- draw boxes too soon
- optimize a system whose priorities are still unclear
- confuse component naming with actual design
BASIC prevents that.
Breakdown: shape the problem before the architecture exists
Good Breakdown separates:
- user goal
- core functional requirements
- non-functional priorities
- assumptions
- out-of-scope features
This is the step that turns “Design X” into a usable task.
Assess: make the trade-off surface visible
Assess is where seniority becomes audible.
The strongest candidates ask:
- Is this read-heavy or write-heavy?
- Where is latency most visible to the user?
- Where do we need consistency and where can we tolerate lag?
- What is likely to become expensive first?
- What operational burden are we accepting?
This is better than jumping to specific tools because it reveals the decision surface.
Structure: give the interviewer something coherent to hold
Structure usually includes:
- the API or interface
- the main components
- the request path
- the data model
- the critical deep-dive area
A request-flow explanation is often more useful than a dense diagram because it lets the interviewer follow cause and effect.
Implement: deepen the part where judgment matters
In system design, Implement is not writing code.
It is taking the chosen shape and going deeper where the risk is real.
Examples:
- ID generation
- deduplication
- caching strategy
- fan-out
- backpressure
- write amplification
- indexing
- abuse controls
The best deep dive is not the fanciest one.
It is the one most likely to decide whether the design holds.
Check: verify pressure points
Good Check includes:
- bottlenecks
- failure modes
- observability
- cost
- operations
- capacity
- what you would revisit with more time
Even a light capacity pass can dramatically improve the feel of the answer because it proves you are not treating the design as a static diagram.
What strong design answers sound like
They sound like this:
- “Let’s define the read and write flows first.”
- “I want to know which latency matters most.”
- “The trade-off here is operational simplicity versus tail-latency protection.”
- “I’ll sketch the request path before I choose the database.”
- “The first thing I would pressure-test is hot-key behavior.”
- “If this system became 10x larger, this component would be where I’d rethink the design.”
That is BASIC in practice.
The one-sentence version
System design BASIC = clarify the job, expose the trade-offs, sketch the shape, deepen the risky part, pressure-test the design.
That is the operating system.