System Design Methodology Questions

A systematic, structured approach to designing software systems and architectures. Candidates should demonstrate how they clarify and refine requirements and constraints, state assumptions, and identify primary and secondary use cases. The methodology includes creating a high level architecture, selecting appropriate components and services with clear reasoning, and explaining data flow and interactions. It requires evaluating non functional requirements such as scalability, availability, performance, security, cost, and compliance, and planning for resilience by describing failure modes and recovery strategies. Operational concerns such as monitoring, logging, backups, disaster recovery, deployment and maintenance should be considered. The candidate should identify trade offs between options, justify design decisions, and show an iterative review and refinement process. At junior or entry levels the emphasis is on demonstrating a disciplined thought process and clear communication of each design step rather than on deep optimizations or domain specific tuning.

EasyTechnical

78 practiced

Identify and prioritize primary and secondary use cases for an e-commerce checkout service (examples: quick checkout, guest checkout, promo codes, multi-shipping). Explain how your prioritization affects the initial architecture, sequencing of features, and rollout strategy to minimize risk while delivering value.

Sample Answer

Primary use cases (must-have first releases)1. Basic checkout (cart → payment → order confirmation) - Rationale: core revenue path; must be reliable and secure.2. Guest checkout - Rationale: reduces friction for new customers; increases conversions quickly.3. Payment integrations (card, tokenized wallets) - Rationale: revenue-critical; pick 1–2 highest-volume providers first.4. Order validation & inventory reservation - Rationale: prevents oversell and chargebacks.

Secondary use cases (phase 2+)1. Promo codes & discounts2. Quick checkout / one-click for returning users3. Multi-shipping (split shipments in one order)4. Save-for-later, address book, tax estimation5. Fraud detection & chargeback workflows (enhanced rules)

How prioritization affects initial architecture- Keep core CheckoutService minimal and transactionally consistent: idempotent API, clear state machine (INIT → VALIDATED → PAID → FULFILLED).- Externalize integrations: payment gateway adapter layer, inventory service, and email/notification service. Use async messaging (events) for non-blocking parts (order confirmation, analytics).- Auth/design: support stateless guest flow and stateful session for logged-in users. Store ephemeral carts in fast datastore (Redis) with persistent order records in relational DB.

Sequencing of features (minimize scope/risk)Phase 1: Basic checkout + guest checkout + single payment provider + inventory reservation + monitoring/logging.Phase 2: Add multiple payment providers, retry/backoff logic, promo codes, stronger fraud checks.Phase 3: Quick checkout (tokenization), multi-shipping, address book, A/B experiments.

Rollout strategy to minimize risk- Feature flags for new capabilities (promo codes, multi-shipping) and gradual percentage rollouts.- Dark-launch payment adapters; run in shadow mode to validate behavior without affecting real transactions.- End-to-end smoke tests and contract tests for gateway and inventory interactions. Canary deploys with real traffic subsets.- Monitor key metrics: checkout conversion rate, payment failure rate, latency, cart abandonment, error & fraud rates. Define rollback thresholds.

Trade-offs and reasoning- Start simple to ensure reliability and fast time-to-value; defer complex flows (multi-shipping) that increase state complexity and testing burden.- Async events reduce latency but require careful eventual-consistency handling (idempotency and compensating actions).- Early investment in modular adapters and feature flags reduces long-term maintenance and enables faster safe rollouts.

This plan delivers immediate revenue impact (basic + guest + payment) while keeping architecture extensible and rollout low-risk through phased releases, monitoring, and feature flags.

HardTechnical

77 practiced

Design a backward- and forward-compatible schema migration strategy for production services with millions of users. Cover additive schema changes, dual-read/dual-write patterns, consumer-driven contract updates, use of feature flags, phased rollouts, validation, and rollback plans for large-scale schema migrations.

Sample Answer

Requirements & constraints:- Zero/low downtime for millions of users, preserve backward & forward compatibility, support multiple consumers/services, ability to validate and rollback, minimal data loss.

High-level approach:1. Prefer additive, non-breaking changes first (new columns, optional fields, new event types).2. Use dual-read/dual-write + consumer-driven contract (CDC) checks to transition consumers.3. Gate behavioral changes with feature flags and phased rollouts.4. Validate continuously and have automated rollback and data migration strategies.

Step-by-step plan:- Design stage - Additive-only schema: add new nullable columns, new optional JSON fields, new event types with clear versioning metadata. - Publish consumer contract: document field types, semantics, required/optional flags, and deprecation timelines. Use schema registry (Avro/JSON Schema/Protobuf) with compatibility rules (backward and forward).- Deployment stage (producer) - Deploy producer code that writes both formats (dual-write) behind a feature flag: keep writing old format and new format concurrently (e.g., write v1 and v2 events/rows). - Start with dual-read logic turned off.- Consumer migration - Consumers subscribe to schema registry. Implement dual-read: read from new field when present, otherwise fallback to old field. Feature-flag consumer behavior to enable new-path for a subset of instances. - Run canary consumers that read only new schema and record mismatches/processing errors to a validation dashboard.- Validation - Use automated validation jobs that compare outputs of old vs new code paths on the same inputs (shadow testing). Collect metrics: processing errors, value diffs, performance, latency, business KPIs. - Run data consistency checks (row counts, hash of serialized payloads, histograms).- Phased rollout - Canary: 1–5% traffic to consumers with new read path; monitor for N minutes/hours. - Gradual ramp: 5→25→50→100% as metrics stay green.- Contract evolution & governance - Use consumer-driven contracts: require consumers to publish tests that verify they accept schema changes. CI validates producer changes against consumer contracts before merge. - Maintain a deprecation schedule and automated alerts to consumers using soon-to-be-removed fields.- Migration & cleanup - After all consumers are on new schema and validation green for a safe window, flip producer to single-write new schema, and deprecate old fields in a planned release. - Run a bounded backfill for historical data if needed (idempotent jobs, rate-limited).- Rollback plan - If validation shows regressions, flip feature flags to revert consumers/producers to old behavior (dual-write ensures no data loss). - If schema change caused persistent incompatibility, stop new writes (feature flag) and rely on dual-write to continue old-format processing. - For data migrations, snapshot before destructive changes; use reversible transformations and maintain migration state so jobs can resume or be rolled back.- Observability & runbooks - Track error rates, consumer contract failures, schema registry violations, processing latency, business metrics. - Prepare runbooks: immediate steps, owners, timelines to rollback producer, rollback consumers, and to run emergency backfills.

Trade-offs & notes:- Dual-write increases write cost and complexity; limit duration and monitor idempotency.- Backfills can be expensive—prefer schema adapters (translate old→new on read) when possible.- Strict consumer contract CI reduces runtime surprises but requires org coordination.

This strategy minimizes user impact by keeping changes additive and reversible, validating at each phase, and giving consumers time and tooling to adapt.

EasyTechnical

71 practiced

Describe your system design methodology when asked to design a new service. Walk through step-by-step how you: clarify and refine requirements, ask specific questions to identify functional and non-functional constraints, state and document assumptions, identify primary and secondary use cases, propose a high-level architecture, select key components, and plan deployment, monitoring and iteration. Give concrete examples of clarifying questions you'd ask for a user-facing web service.

Sample Answer

I follow a structured, repeatable methodology that surfaces requirements, constraints, and trade-offs early, then iterates from high-level to implementation and operations.

1) Clarify & refine requirements- Ask targeted questions: Who are users (internal/external)? Expected peak QPS? Success metrics (latency, availability, errors)? Data size and retention? Regulatory constraints? Example for a web service: “Do users need real-time updates or eventual consistency?” “What’s acceptable 95th/99th percentile latency?” “Do we need multi-region support?”

2) Identify functional & non-functional constraints- Functional: auth, search, file upload, notifications.- Non-functional: SLAs, throughput, cost, security, privacy, backup, compliance.

3) State and document assumptions- Record defaults if PO can’t decide: e.g., “assume 10k daily active users, 100 RPS peak, 1M stored objects, single-region initially.” Mark which assumptions to validate.

4) Primary vs secondary use cases- Primary: user login, browse, create content, read content.- Secondary: analytics, admin tools, bulk imports, export.

5) High-level architecture- Present a diagram verbally: Load balancer → API gateway → stateless app servers (autoscaled) → services: auth, user/profile, content service → databases (OLTP + read replicas) → object store for media → caching layer (Redis / CDN) → async queue/workers.

6) Select key components & rationale- API Gateway for routing, rate-limiting.- Relational DB for transactional data; NoSQL for flexible schema or large-scale reads.- CDN + object store for media to reduce origin load.- Message queue (Kafka/RabbitMQ) for async tasks and resiliency.

7) Deployment, monitoring, iteration- CI/CD pipelines, blue-green or canary deploys.- Metrics: latency percentiles, error rates, CPU/memory, queue depth.- Alerts + runbooks; distributed tracing (OpenTelemetry), logs (ELK/Datadog).- Plan capacity tests and gradual scale: start single region, instrument, load test, then add replication/geo.

Concrete clarifying questions for a user-facing web service:- Who is the primary user persona and expected growth rate?- Peak traffic patterns (daily/seasonal) and SLAs?- What data must be consistent vs eventually consistent?- Required retention and compliance (GDPR, HIPAA)?- Offline support or mobile constraints?- Allowed budget for infra and latency targets for 95th/99th percentiles?

This methodology keeps design decisions traceable, makes trade-offs explicit, and enables fast iteration once real metrics replace assumptions.

MediumSystem Design

54 practiced

Design a distributed rate limiter that enforces 'no user may exceed 100 requests per minute' in a system that receives 10k requests/sec across many app servers. Discuss algorithm choices (token-bucket, sliding window), centralized vs local implementations, where to store counters, and how to handle clock skew and enforcement latency.

Sample Answer

Requirements & constraints:- Functional: limit each user to 100 requests/minute.- Non-functional: 10k req/s total, low latency (<5ms added), high availability, eventual consistency acceptable for short windows.

Algorithms:- Fixed window counter: simple but suffers from boundary spikes (200 req at boundary).- Sliding window log: precise (store timestamps per user) but storage/IO heavy.- Sliding window counter (approx): two fixed windows with weighted interpolation — good accuracy vs cost.- Token bucket (leaky-bucket variant): smooths bursts, supports refill rate = 100/min; good for per-request checks.

Centralized vs local enforcement:- Centralized (single service/Redis): strong global accuracy, simpler correctness, but single point of failure and added latency.- Local (each app server with local token-bucket): low latency, high availability, but needs sync to prevent users exceeding global limit across servers.- Hybrid: local fast-path + periodic global reconciliation. Accept short-term overages; enforce strict limit at global store for backstop.

Storage & architecture:- Use Redis (clustered) as centralized counter/token store with atomic ops (INCR with EXPIRE, or Lua scripts for token-bucket) for correctness and speed. Redis supports high QPS and low latency.- Shard keys by user-id (consistent hashing) to distribute load across Redis nodes.- Use a small in-memory cache on app servers (e.g., local token-bucket) for micro-bursts; check Redis only when local tokens exhausted.

Handling clock skew:- Avoid relying on client or app-server clocks for correctness. Use server-side timestamps from a coordinated NTP, but preferably use Redis TTL/atomic timestamps returned from Redis to drive window boundaries.- For sliding log approaches that store timestamps, use monotonic server time.

Enforcement latency & consistency:- Optimize Redis calls: use Lua scripts to perform check-and-update atomically in one round-trip.- For 10k req/s and per-user granularity, aggregate hot users (rate-limit by IP or API key) and use backpressure for hotspots.- Hybrid approach: app checks local token-bucket; if uncertain or exhausted, call Redis Lua script. This yields sub-ms local checks and ~1-5ms for global checks.

Trade-offs:- Accuracy vs latency: centralized Redis + Lua = accurate, slightly higher latency. Local-first = low latency, eventual global correctness.- Storage vs precision: sliding log is precise but costly. Sliding counter or token bucket is efficient and acceptable for most use cases.

Operational notes:- Monitor Redis latency and QPS; autoscale Redis cluster and use client-side circuit-breakers.- Provide clear error responses (429) and headers indicating remaining quota and reset time.- Write integration tests and chaos tests for partitions and clock drift to validate safety under failure.

EasyTechnical

63 practiced

List common failure modes for a single stateless API service under heavy load (e.g., CPU saturation, memory pressure, downstream timeouts) and propose simple, practical recovery or mitigation strategies such as autoscaling policies, circuit breakers, graceful degradation, and load shedding.

Sample Answer

Approach: list common failure modes for a stateless API under load, explain why they occur, then give simple, practical mitigations you can implement quickly.

Failure modes and mitigations:

1) CPU saturation — overloaded request processing (high compute per request)- Mitigation: autoscaling based on CPU + request latency; move heavy work to background jobs/worker queues; optimize hot paths (caching, reduce serialization).- Short-term: reject or throttle expensive endpoints (rate limits).

2) Memory pressure — per-request allocations or large in-memory caches- Mitigation: set container memory limits and OOM thresholds; use streaming/parsing to avoid large buffers; reduce cache sizes or use LRU.- Short-term: restart instances gracefully on OOM, and use rolling restarts.

3) Thread / file descriptor exhaustion — too many concurrent connections- Mitigation: tune server thread pool / connection limits; use async/non-blocking servers; enable keep-alive controls.- Short-term: enforce connection/read timeouts; backpressure responses (503 + Retry-After).

4) Downstream timeouts / cascading failures (DB, external APIs)- Mitigation: implement circuit breakers with failure thresholds and exponential backoff; use timeouts shorter than client TTL; add retries with jitter.- Short-term: degrade features that depend on downstreams (return cached or partial responses).

5) High latency / queueing (head-of-line blocking)- Mitigation: prioritize critical endpoints; use admission control/load shedding to drop low-value requests; add priority queues.- Short-term: return tiered responses (lightweight fallback) and expose graceful degradation.

6) Thundering herd at startup or deploys- Mitigation: stagger rolling deployments, readiness probes, and warm-up cache; pre-warm instances.- Short-term: return 503 until healthy.

Operational policies:- Autoscaling: combine CPU, request rate, and p95 latency triggers; use cooldown windows to avoid flapping.- Observability: instrument metrics (CPU, mem, latency, errors, queue lengths), alert on p95/p99.- Graceful shutdown: stop accepting new requests, finish in-flight work, then terminate.- Load shedding: prefer controlled 429/503 with Retry-After over unbounded failures.

These strategies prioritize quick, automatable defenses (timeouts, circuit breakers, autoscale, rate limits) and progressive improvements (async design, caching, decomposition).

Unlock Full Question Bank

Get access to hundreds of System Design Methodology interview questions and detailed answers.

Join thousands of developers preparing for their dream job.