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

64 practiced

Explain the differences between SLA, SLO, and error budget. For a public API with a contractual availability SLA of 99.95%, propose SLOs you would set, how you calculate/measure them, and how you would present the error budget to the customer and engineering teams.

Sample Answer

SLA vs SLO vs Error budget — short definitions:- SLA (Service Level Agreement): a contractual promise to the customer (e.g., 99.95% availability) often with financial/penalty terms.- SLO (Service Level Objective): an internal (but shareable) measurable target derived from business requirements that guides operations (e.g., 99.97% successful requests over 30 days).- Error budget: 1 − SLO (or allowable failure) over an interval; it quantifies how much unreliability is acceptable before action is required.

Proposed SLOs for a public API with contractual SLA = 99.95% availability:- Availability SLO: 99.95% successful HTTP 2xx responses across global traffic, rolling 30-day window (matches SLA for customer-facing reporting).- Latency SLO: 95th percentile p95 < 200ms for GET endpoints, 99th percentile p99 < 500ms for critical endpoints, rolling 30-day window.- Error-rate SLO: total server errors (5xx) < 0.05% of requests over 30 days.- Regional SLOs: availability per region (US/EU/APAC) ≥ 99.9% to catch localized issues.

How to calculate / measure:- Measure at ingress load balancer / API gateway to capture customer-observed success (status codes, latency, region tags).- Use rolling windows (30-day and 7-day) and calculate: Availability = (successful requests) / (total requests) * 100.- Compute percentiles with sliding-window histograms (HDR histograms) to avoid distortion by outliers.- Exclude planned maintenance (pre-notified) per SLA rules and annotate incidents.

Presenting the error budget:- To customers: a concise monthly report showing SLA attainment (99.95% target), incidents that consumed the budget (time, impact), and remediation timelines. Show earned/remaining error budget as "% of month" or "minutes remaining" and a simple traffic-light: green = >50% remaining, yellow = 10–50%, red = <10% or breach.- To engineering teams: an operational dashboard with real-time burn rate, per-region and per-service SLOs, and automatic alerts when burn rate exceeds threshold (e.g., projected to exhaust budget in 7 days). Tie error-budget policies to actions: throttling riskier deploys, freezing non-critical changes when budget low, and triggering postmortems when budget breaches occur.- Communicate trade-offs: SLOs guide engineering priorities while SLA defines contractual exposure; ensure both sales/legal and engineering agree on measurement, maintenance windows, and penalty clauses.

EasySystem Design

57 practiced

You're preparing a one-page high-level architecture diagram for a non-technical executive. What elements must it include (components, high-level data flow, user personas, key SLAs, constraints, and major risks), and how would you annotate it to communicate trade-offs and implementation complexity without technical diagrams?

Sample Answer

For a one-page, non-technical executive-facing architecture I would include these clear, scannable elements and annotate them to surface trade-offs and complexity:

Required elements (visual blocks + short labels)- User Personas — 2–4 icons and one-line goals (e.g., “Customer: browse + purchase”; “Ops: monitor & restore”)- Business Capabilities / Components — big labeled boxes (Web App, API Gateway, Order Service, Data Warehouse, Admin Console)- High-level Data Flow — numbered arrows showing primary flows (1: browse → 2: place order → 3: payment → 4: fulfillment)- External Integrations — PCI payment provider, 3rd-party shipping, Identity Provider (shown as clouds)- Key SLAs / Non-functional targets — small table or side callouts (availability 99.95%, <200ms page load, RTO 1hr)- Constraints — regulatory (PCI, GDPR), budget, timeline, legacy systems- Major Risks — top 3 bullets with business impact (e.g., “Payment provider outage → revenue loss”)

Annotation approach to communicate trade-offs & complexity (non-technical language)- Use plain-language trade-off callouts adjacent to components: e.g., “Autoscaling DB: +scalability, -higher cost, +operational complexity”- Color-code complexity/risk: green = low, amber = medium, red = high. Add legend.- Use simple icons for effort level (clock for timeline impact, $ for cost, shield for security risk)- Add 1–2 decision options with bullets and pros/cons (Option A: SaaS payments — faster to market; Option B: in-house gateway — more control, higher cost)- Include a single “implementation complexity” bar per major component (low/medium/high) with one-sentence justification

Presentation tips- Keep text to one line per annotation; use callouts and numbering to guide spoken narrative- Provide an executive summary box: objective, recommended option, top 3 risks & mitigations- Leave space for Q&A and action items (next steps: POC, security review, cost estimate)

This format tells the story visually, highlights where trade-offs lie, and equips executives to make decisions without technical diagrams.

EasyTechnical

115 practiced

You're designing a B2C e-commerce checkout flow. List primary (must-have) and secondary (nice-to-have) use cases and explain why you categorized them that way. Provide a prioritized list and state assumptions about traffic patterns, device mix, payment methods, and acceptable latency for checkout completion.

Sample Answer

Assumptions (to scope priorities)- Peak traffic: 2k concurrent checkouts, average 200 orders/min; bursty around promotions.- Device mix: 60% mobile, 35% desktop, 5% tablet.- Payment methods: cards (Visa/MC/Amex), digital wallets (Apple Pay/Google Pay), buy-now-pay-later (BNPL), gift cards.- Acceptable end-to-end checkout latency: <= 5s on mobile (ideal ≤3s), <=3s on desktop.

Primary (must-have) use cases — prioritized and why1. Guest checkout with card payment - Rationale: Lowest friction; highest conversion impact; must be reliable and fast.2. Registered user checkout with saved addresses and cards - Rationale: Improves conversion/retention; supports faster repeat purchases.3. Mobile wallet checkout (Apple/Google Pay) - Rationale: Preferred on mobile; reduces typing and fraud; high conversion lift.4. Order review and total calculation (tax, shipping, discounts) - Rationale: Accuracy/legal requirement; prevents disputes/refunds.5. Secure payment authorization and tokenization (PCI scope minimization) - Rationale: Security/compliance; foundational for all payments.6. Inventory & price validation at checkout commit - Rationale: Prevents oversell and chargebacks.7. Confirmation page + email receipt - Rationale: Customer trust and order tracking initiation.

Secondary (nice-to-have) use cases — prioritized and why1. BNPL & alternative payment methods - Rationale: Increases AOV; lower immediate adoption than cards but important for segments.2. Promo code / loyalty/auto-apply best discount - Rationale: Improves UX and conversions; complexity in rules engine.3. Multi-currency and localization - Rationale: Important for international scale; not required at launch if single-market.4. Saved cart synchronization across devices - Rationale: Boosts conversions for registered users; lower initial priority.5. Address autocomplete and validation (third-party integration) - Rationale: Improves accuracy and speed; optional if manual works.6. One-click reorder / subscriptions - Rationale: Valuable for retention but requires billing/subscription infra.7. Split payment / gift card + card - Rationale: Rare but increases flexibility.

Trade-offs and reasoning- Primary cases focus on conversion, compliance, accuracy, and performance — core to revenue and risk.- Secondary cases improve experience and revenue over time but add integration complexity and latency risk.- Prioritize features that minimize PCI scope (tokenization), reduce friction (guest + wallets), and ensure correctness (inventory/pricing).

Operational notes- Cache pricing rules and offer calculation where safe; validate authoritative price at commit.- Use asynchronous email and background tasks to keep user-facing latency low.- Plan payment gateway redundancy and rate limits to handle bursts.- Monitor conversion funnels, payment failure rates, and latency to re-prioritize secondary features.

MediumSystem Design

74 practiced

You're designing a RESTful product-catalog API that must handle 1M daily requests with complex filtering and sorting. Describe endpoint design, pagination strategy (cursor vs offset), caching recommendations, rate limiting, versioning approach, and practical optimizations to reduce latency.

Sample Answer

Requirements & constraints:- 1M requests/day (~12 req/s average, ~200 req/s peak with bursts), complex multi-field filters & sorts, low latency (P95 < 200ms), eventual consistency acceptable for some reads.

Endpoint design (RESTful):- GET /v1/products — primary listing with query params for filters (category, price_min, price_max, brand, attributes...), sort, pagination token.- GET /v1/products/{id} — single product- POST /v1/products, PUT /v1/products/{id}, DELETE /v1/products/{id} — admin operations (authz)- /v1/products/aggregations — precomputed facets for UI filters

Pagination strategy:- Use cursor-based pagination for list endpoints: return next_cursor (opaque, base64 with sort key + tie-breaker). Reasons: stable across inserts/deletes, efficient for deep pages, and aligns with indexed range scans for sorted queries.- Offer limited offset for small-page analytics but rate-limit or cap max offset to avoid heavy scans.

Caching recommendations:- CDN + edge caching for common queries (keys include normalized querystring). Short TTLs (30–120s) for product lists; longer TTLs for product details (5–60 min) and purge on updates via cache invalidation events.- Application-level cache (Redis) for hot filter combinations and precomputed facets.- Use cache aside pattern and Bloom filters to avoid DB hits for missing IDs.

Rate limiting & throttling:- Per-client (API key) token bucket: burstable with steady rate. Example: 200 req/min per key with stricter limits on heavy filter combos.- Global protective limits and dynamic throttling (429 + Retry-After). Monitor and apply stricter SLAs for paid tiers.

Versioning approach:- URI versioning (/v1/...) for major breaking changes. Use feature flags and ETags for incremental changes. Support content negotiation (Accept header) only for minor evolutions when needed.

Practical latency optimizations:- Index design: composite indexes that match common filter+sort patterns; cover queries to avoid lookups.- Search engine (Elasticsearch / OpenSearch) for complex filtering/sorting and relevancy; keep product of record in primary DB and near-real-time sync to search index.- Denormalize read model (materialized views) for frequent combos.- Query tuning: limit returned fields, implement projection, and use pagination cursors that leverage indexed sort keys.- Connection pooling, keep-alive, and async workers for heavy transforms.- Observability: detailed metrics, slow-query logging, and A/B tests for cache TTLs.

Trade-offs:- Search index adds complexity and eventual-consistency but drastically reduces latency for complex filters.- Cursor pagination is more complex for clients but scales far better than offset for deep paging.

EasyTechnical

78 practiced

What key sections should a solution architecture document contain for client sign-off? Provide a template outline including purpose, scope, requirements, assumptions, high-level architecture, component responsibilities, non-functional requirements (NFRs), security, deployment plan, migration path, risks, and appendix with diagrams and cost estimates.

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.