Katkat
Back

Design and explain your project architecture

TikTokSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

A TikTok software-engineer system-design screen that asks you to walk through one of your recent projects end-to-end: architecture diagram, components and data stores, sync vs. async data flows and protocols, scaling and capacity planning, fault tolerance, backpressure, idempotency, observability, and security. It also probes the design trade-offs you made, the real failure modes you hit, the measurable impact, and what you would redesign. Includes a fully worked reference answer plus the scoring rubric.

Question

Pick one of your recent projects and walk an interviewer through its architecture end-to-end. Sketch a high-level diagram, then go deep on the design, the trade-offs you made, and how you would evolve it. Be ready for deep-dive follow-ups on any single component.

Cover the following:

  1. Diagram & components. Draw the high-level architecture. Walk through the core components, data stores/data model, external dependencies, and deployment topology (regions, AZs, orchestration).
  2. APIs & data flows. Describe the key APIs and how data moves through the system: which paths are synchronous vs. asynchronous, and which protocols you used (HTTP/REST, gRPC, message bus).
  3. Design decisions & trade-offs. Justify your major decisions and the alternatives you rejected. Tie each decision back to constraints such as latency, throughput, and cost.
  4. Scaling & capacity planning. Explain how the system scales and show how you sized it (QPS, bandwidth, compute). Quantify the key constraints.
  5. Fault tolerance, backpressure, idempotency & retries. Describe how the system stays up under partial failure — replication, circuit breakers, bounded queues/backpressure, idempotent operations, retry policy, and dead-letter handling.
  6. Observability. Logging, metrics, and tracing across both synchronous and asynchronous boundaries, and the SLOs/error budgets you tracked.
  7. Security. AuthN/authZ, secrets management, and PII handling/data protection.
  8. Failure modes you actually hit. Walk through real incidents: symptom, root cause, how you detected it (alerts/SLIs), how you mitigated it, and the permanent fix — with concrete metrics.
  9. Results & impact. Share concrete numbers (latency, quality, reliability, cost) that demonstrate the impact of your work.
  10. What you'd redesign. Given another chance, what would you change, and why?