Senior SDEs, staff, and architects

System Design Interview Practice

A system design mock interview is practice explaining requirements, estimates, architecture choices and failure handling under questions and time constraints. State your assumptions, connect each major component to a need, and discuss trade-offs. MockWise supports a spoken or typed design interview with transcript feedback; it does not assess a drawn diagram or certify an employer’s design standard.

Published by MockWise. This update was AI-assisted and checked against the linked sources and current product code. Worked examples are synthetic, not real candidate results.

Source and implementation check: 2026-10-02 · Named human editorial review pending

Requirements and estimates
Worked retry design
Failure paths and trade-offs

How should I structure a system design answer?

This is a suggested explanation framework, not a universal grading formula. The interviewer may direct the discussion toward a different concern; follow the supplied task rather than forcing every answer through all five steps.

Clarify the user journey, scope and constraints. Ask which operations need strong consistency and what can be delayed.
Estimate the relevant load using explicit assumptions: request rates, payload sizes, storage growth or fan-out. Explain which decision depends on each estimate.
Describe one request path through the API, data store and any asynchronous work. Start simply and add components when a requirement justifies them.
Choose a difficult component for a deep dive: keys and schema, duplicate handling, contention or recovery.
Compare an alternative, walk one failure and name the operational signals you would use to revisit the design.

System design framework: Use the companion framework for further practice; employer-specific formats and scoring may differ.

Worked design: a job submission API that tolerates retries

Synthetic exercise: a reporting service accepts 100 jobs per second, each with a 2 KB request. These invented assumptions are a teaching input, not MockWise production traffic or a measured candidate result.

Requirements and estimate

Clients submit jobs and poll for status; a retried request should not create a second job. For the exercise, 100 × 2 KB is roughly 200 KB of raw input per second, before protocol and storage overhead. This estimate does not establish storage capacity or peak headroom.

Request and data path

Require a client token for submission. Store the token, a hash of the relevant input and a job row together in a database transaction with a uniqueness constraint on the scoped token. Return the existing job identifier for a matching duplicate; reject reuse of the token for conflicting input.

Queue handoff and worker

Write an outbox entry in the same transaction as the job, then let a dispatcher enqueue it. The dispatcher can retry, so the worker must also tolerate duplicate delivery. Track job state and make each downstream side effect retry-safe; a token at the API boundary alone is insufficient.

Failure and trade-off

If the client loses the response after commit, it retries with the same token and receives the existing job. Token retention limits how long that protection lasts. A worker crash after a downstream side effect needs a way to reconcile or deduplicate at that downstream boundary; do not claim exactly-once behavior merely because a queue is present.

Operational check

Monitor queue age, failed dispatches, worker retries and completion latency. Test concurrent submissions and crashes at each handoff. Partitioning or more workers should follow the measured bottleneck, not the vocabulary of a reference diagram.

AWS: make mutating operations idempotent: Explains tokens and atomic state management for avoiding repeated side effects when requests are retried.

What should I practice beyond one architecture?

Topic relevance and expected depth vary by role and employer. These are practice choices, not a list of guaranteed questions or an experience-to-score mapping.

Feeds, chat and notifications

Practice the cost of fan-out, ordering scope, retries and how the user experience changes when delivery is delayed. A design for notifications is not automatically a feed-ranking design.

Storage and caching

Choose keys from access patterns. Discuss hot keys, invalidation, stale reads and what happens when a replica or cache fails; hashing alone does not spread one frequently accessed key.

APIs and background work

Define contracts, quotas, duplicate behavior, admission control and cancellation. Explain whether a failed operation is safe to retry and how the client learns its state.

Migration and growth

Describe how an initial design evolves, how to validate a migration and how to recover from a failed cutover. Requirements and team constraints may justify a simpler starting point.

What does MockWise provide for system design practice?

Choose System Design with a selected resume, duration and difficulty. Optional job description and instructions can request topics. The selected 30- or 60-minute duration does not guarantee one versus two design prompts or a behavioral closing round.

Explain the architecture by voice or text. Draw separately if the real interview needs a diagram, and use a partner when you need feedback on the drawing workflow. The report reviews the conversation; it does not execute a load test or assess pixels.

Question analysis, missed points, knowledge gaps and a learning roadmap can suggest next exercises. A dedicated trade-off matrix and fixed Requirements/Estimation/HLD score sections are not established by the report format checked for this guide.

Read an interview feedback report: Explains the report fields and how to check feedback against what you actually said.

MockWise pricing: Check the current offer before starting another scored session: 30 minutes costs one credit and 60 minutes costs two.

How do I check whether my design explanation improved?

Compare the stated requirements and which choices they justified, not just the score.
Verify a disputed technical claim with documentation and identify any database- or provider-specific behavior.
Add a new failure or constraint and explain the revision without reciting the original topology.
Rehearse independently between scored sessions. Create a new interview for another report; completed sessions cannot be replaced.

PostgreSQL 18: transaction isolation: Documents PostgreSQL-specific isolation behavior. Repeatable Read prevents phantom reads here, but serialization anomalies remain possible.

Example questions and ideal structure

Intermediate

Design a retry-safe background job submission API.

Ideal structure: Clarify duplicate semantics, scope the token, store job and token atomically, plan durable handoff and make downstream work retry-safe. State the retention boundary and failure cases.

Follow-up to expect: What if the worker crashes after applying a side effect?

Advanced

How would you design a notification service for bursty traffic?

Ideal structure: State delivery and ordering requirements, estimate peak load, discuss queue capacity, backpressure, provider failures and duplicate handling. Choose push or pull behavior according to the product requirement.

Follow-up to expect: Which messages can expire while a provider is unavailable?

Advanced

How would you partition a chat message store?

Ideal structure: Compare conversation-based and other keys against read and write patterns. Discuss a hot conversation, ordering scope, retention and the cost of cross-partition reads.

Follow-up to expect: What changes when one group dominates the traffic?

Intermediate

Design a URL shortener with click analytics.

Ideal structure: Separate identifier encoding from identifier generation. Base-62 encoding alone does not hide a sequential counter. Discuss collision handling, redirect latency, abuse controls and whether analytics may be delayed or lost.

Follow-up to expect: How will you avoid losing or duplicating events after a worker crash?

How to prepare

Keep assumptions visible and connect them to decisions.
Walk a failure path as well as the happy path.
Use documentation to check semantics and tests to check your design where practical.
Adapt depth to the actual task; no universal architecture or score cutoff applies.

FAQs

Do I have to draw in MockWise?

The reviewed interview flow uses voice or text, and the report evaluates conversation text. Draw separately if useful; confirm whether the employer expects a shared whiteboard.

Does a 60-minute mock guarantee two prompts?

No. Duration is selected in the setup, but generated questions and the session structure may vary. It does not guarantee two design prompts or a behavioral close.

Does the report include a trade-off matrix?

The current report format includes question evaluation, a technical competency matrix, knowledge gaps, communication review and a learning roadmap. A dedicated trade-off matrix is not established by the implementation checked here.

How should I use a model answer?

Use it to inspect assumptions and alternatives, then adapt it to changed requirements. A worked example is not a universal passing architecture or a substitute for verifying technical claims.

Ready to practice?

Practice your answers in a mock interview, then review the transcript-based feedback.