System Design Problem Solving and Methodology Questions

A structured approach to solving open ended system design problems during interviews. Emphasis on requirement gathering and clarifying questions, making and stating assumptions explicit, calculating capacity and load estimates, identifying and prioritizing bottlenecks, proposing modular and testable solutions, and articulating trade offs with respect to performance cost reliability and time to implement. Also covers communication of ideas using diagrams, incremental delivery and backward compatible changes, and how to justify design decisions under uncertainty.

EasyTechnical

111 practiced

You're asked to design a URL shortening service in an interview. Before drawing architecture, list the clarifying questions you'd ask to scope the problem. Cover functional (custom aliases, analytics, API vs UI), non-functional (traffic, availability, latency targets), operational (data retention, abuse/malicious links), and business (monetization, analytics required) concerns. Explain why each question matters and how the answers change architecture choices.

Sample Answer

Below are the clarifying questions I’d ask, grouped by concern, with why each matters and how the answer would change architecture choices.

Functional- Who are the users: internal, public, or enterprises? Why: affects auth, rate limits, SLA, and multi-tenant design. Architecture impact: public service → stronger abuse controls and scalable public APIs; enterprise → tenant isolation, RBAC.- Require custom aliases or vanity domains? Why: custom aliases need uniqueness checks and collision handling; vanity domains need DNS and CNAME support. Impact: add alias reservation service, domain mapping table, validation flow.- Web UI, public API, SDKs, or all? Why: determines throughput patterns and auth methods (API keys/OAuth). Impact: design API gateway, client libraries, CORS, versioning.- Analytics needed (click counts, geolocation, referrer, device, real-time)? Why: influences data model, storage and processing (streaming vs batch). Impact: event pipeline (Kafka), OLAP store for reporting, real-time counters vs periodic aggregation.- Link expiration, password protection, or previews? Why: adds metadata and access-control rules. Impact: include TTL fields, auth middleware, preview microservice.

Non-functional- Expected QPS and growth rate? Why: sets capacity planning and component sizing. Impact: choice of DB (NoSQL vs RDBMS), cache strategy, sharding, CDN.- Availability and durability targets (e.g., 99.99%)? Why: influences redundancy, multi-AZ/region, backup/replication. Impact: multi-region deployment, consensus/replication, failover design.- Latency requirements for redirection and analytics queries? Why: redirects must be low-latency; analytics can be eventually consistent. Impact: use in-memory cache (Redis) for redirects; asynchronous event processing for analytics.- Consistency model for alias creation (strong vs eventual)? Why: collisions and correctness of custom aliases. Impact: use distributed locking or strongly consistent store for alias writes.

Operational- Data retention and GDPR/CCPA requirements? Why: affects deletion workflows and data partitioning. Impact: soft-delete vs purge jobs, audit logs, encryption, data residency.- Abuse detection and malicious links policy? Why: need scanning, rate limits, user reporting, takedown workflows. Impact: integrate URL-safety APIs, spam heuristics, admin dashboard, quarantine pipeline.- Backup, monitoring, alerting, and runbook expectations? Why: operational readiness and incident response. Impact: metrics (Prometheus), logging, SLOs, automated alerts, playbooks.- Support and incident SLAs? Why: defines on-call, escalation, and business continuity plans.

Business- Monetization model (ads on redirect, paid features, analytics subscriptions)? Why: shapes product features and data collection needs. Impact: ad insertion layer, billing integration, premium feature gating.- Required business metrics and dashboards? Why: determines analytics fidelity and freshness. Impact: invest in real-time dashboards or periodic reports.- Legal/compliance (copyright, local laws)? Why: affects content scanning and retention. Impact: implement content filters, takedown logging, region-specific storage.

Each answer narrows scope and drives concrete choices: storage type and schema, sync vs async flows, security and abuse controls, scaling and replication strategies, and operational overhead. Starting with these questions ensures the architecture fits real requirements rather than assumptions.

MediumSystem Design

59 practiced

Design a backward-compatible change strategy for a public REST API served to 1 million clients. Explain possible approaches: additive fields, optional headers, content negotiation, versioning strategies (URI vs header vs media type), deprecation timeline, client negotiation, testing, and communication plan. Show how you'd make a breaking change with minimal disruption.

Sample Answer

Requirements & constraints:- Serve 1M clients with minimal disruption, low latency, backwards compatibility prioritized, ability to phase out old behavior, telemetry to measure adoption, clear communication.

High-level strategy:- Prefer additive, non-breaking changes by default. Reserve breaking changes only when unavoidable and mitigate with versioning + negotiation + deprecation timeline.

Approaches (short):- Additive fields: Add new JSON fields; clients ignore unknown keys. Use null vs omitted semantics consistently and document defaults.- Optional headers: New capabilities exposed via opt-in headers (e.g., Prefer: response=full) so old clients unaffected.- Content negotiation: Support Accept / Content-Type variations for media-type evolution; include profile parameters (application/json; profile="v2").- Versioning strategies: - URI versioning (/v2/resource): Simple, visible; easier for caching and routing but encourages duplication. - Header versioning (X-API-Version): Cleaner URIs; requires client/edge support; harder to debug. - Media-type versioning (Accept header): RESTful, precise control; best for evolvable media types. Pick one primary (media-type or header) and fallback mapping from URI for ease of use.

Deprecation timeline & policy:- Announce changes 90+ days before enforcement for critical clients; for enterprise customers allow longer.- Phases: announcement -> opt-in preview (beta) -> parallel support (both versions) -> deprecation warning in responses -> cutoff.- Provide automated fallback window and rollback plans.

Client negotiation & migration:- Support both old and new behavior concurrently. Implement server-side feature flags to route by version header/Accept/URI.- Provide SDK updates, migration guide, code snippets, and compatibility shims.- Offer a “compat” header that enables server-side transformation for old clients during transition.

Testing & rollout:- Contract tests (consumer-driven contracts) between service and client SDKs.- Backwards-compatibility tests in CI (schema validation against old contract).- Canary releases: small % to v2, monitor errors, latency, business metrics; expand gradually.- Observability: log version usage, deprecation warnings seen by clients, error rates, and feature flag metrics.

Communication plan:- Multi-channel: API changelog, email to registered clients, dashboard notice, in-response warning headers (Deprecation, Sunset, Link to docs), status page updates, and migration webinars.- Provide sample code and automated migration tools.

Making a breaking change with minimal disruption (example: renaming field "createdAt" -> "created_timestamp"):1. Additive step: Keep createdAt, add created_timestamp (same value). Mark createdAt as “deprecated” in docs.2. Opt-in preview: Introduce header Accept: application/json; profile="v2" which causes responses to include only created_timestamp (or both depending on preview).3. Telemetry: Track clients using createdAt vs created_timestamp.4. Deprecation warning: For requests missing profile header, return Deprecation and Warning headers starting after preview.5. Cutover: After adoption threshold (e.g., 95% migrated) and 90-day notice, remove createdAt. Provide a final endpoint /v2/* requiring media-type header for strict contracts.6. Rollback plan: Feature-flag removal; ability to re-enable createdAt if errors spike during cutover.

Trade-offs:- URI versioning is easiest for caching and proxies but less REST-pure. Media-type versioning is most flexible but needs client sophistication.- Longer deprecation windows reduce disruption but increase maintenance cost.

This plan minimizes disruption by making changes additive first, enabling opt-in previews, using clear negotiation/version controls, rigorous testing and telemetry, and a transparent, timeboxed deprecation/communication process.

HardSystem Design

58 practiced

Design a globally distributed user profile service for 200 million users that provides low read-latency (<50ms) worldwide and ensures write-after-read consistency within a user's home region. Describe how you would partition data, replicate profiles across regions, handle reads from nearest region, resolve conflicting writes, and quantify expected replication lag. Discuss SLOs and trade-offs between freshness and availability.

Sample Answer

Requirements and constraints:- Functional: store 200M user profiles (small payloads ~1–10KB), global low read latency (<50ms), write-after-read consistency within user’s home region.- Non-functional: high availability, eventual cross-region convergence, bounded replication lag, economical.

High-level architecture:- Each user assigned a home region (typically where they registered). Use geo-DNS + anycast for routing.- Partitioning: consistent hashing by userID with region-aware ownership (primary shard lives in home region; replica shards in N other regions). Partition size tuned so each shard fits on cluster nodes (e.g., 1M users/shard).- Storage: per-region storage clusters (e.g., CockroachDB/Cassandra-like with local leader per shard or a custom service using Raft per-shard). Use SSD-backed stores and in-memory caches (Redis or local LRU) for hot profiles.

Reads:- Read from nearest region’s replica. If the reader is in the user’s home region, read from primary leader for strong write-after-read consistency. If in remote region, read from local replica for latency; if strong freshness required, route to home-region leader (trade-off).- Serve reads from read-through cache. Use TTLs and validation via vector timestamps when freshness demanded.

Writes:- Writes are directed to the user’s home-region leader (write-affinity). Home leader applies Raft/consensus locally, returns success to client once durable, then asynchronously replicate to other regions.- For cross-region failover, elect a temporary regional leader with epoch-based lease tied to home-region unreachable detection.

Conflict resolution:- Single-writer-per-user (home-region leader) avoids conflicts. For multi-writer cases (e.g., offline clients or split-brain), use last-writer-wins with hybrid logical clocks (HLC) to preserve causal order, plus application-level merge hooks for complex fields (lists, preferences) using CRDTs for commutative merges where appropriate.

Replication and expected lag:- Synchronous within home-region replicas (sub-50ms local). Cross-region replication is asynchronous via fine-grained change logs (Kafka/CDC) over WAN. Expected median cross-region lag: 50–200ms intercontinental (based on network RTT + apply time); 95th percentile 300–500ms. Use batch tuning and prioritized hot-user replication to reduce perceived lag.

SLOs and monitoring:- Read latency SLO: 99th percentile <50ms per region (measured at edge). Write durability SLO: acknowledged by home-region leader within 100ms. Replication freshness SLO: 99% of replicas converge within 500ms for active users. Use metrics: RTT, apply lag, replication queue, error rates; alert on tail latency and lag spikes.

Trade-offs (freshness vs availability):- Favor low-latency reads by serving from local replicas at the cost of short-term staleness. For strict freshness, route to home-region leader (higher latency). Provide per-request consistency levels: “strong” (home leader), “bounded-staleness” (guaranteed within X ms), “eventual” (nearest replica). During partition, prefer availability for reads (serve stale) but maintain write correctness by funneling writes to home-region leader—if home unreachable, choose either reject writes (consistency-first) or accept with conflict resolution via HLC/CRDTs (availability-first).

Operational considerations:- Automatic re-sharding, leader transfer tooling, backpressure for replication, geo-aware caching invalidation, periodic full consistency scans, and disaster recovery playbooks. Test with chaos engineering for region outages and measure real-world replication lag to tune SLOs.

MediumTechnical

59 practiced

Explain how to compute and interpret tail latency (e.g., p95, p99) during capacity planning. Provide a short worked example: given measured p50=20ms, p95=120ms, p99=300ms at 10k RPS, explain what those numbers mean for user experience and how you would provision headroom to meet a p99 latency target of 200ms under a 1.5x traffic spike.

MediumTechnical

73 practiced

Design a consistent hashing scheme for routing keys to cache nodes. Explain how to minimize remapping when nodes are added/removed, how to handle virtual nodes, replication for fault tolerance, and how to detect and handle hot keys. Discuss operational concerns like rebalancing and monitoring.

Sample Answer

Situation: Design a consistent-hashing-based router for mapping keys to cache nodes that minimizes remapping, supports replication and failure tolerance, handles hot keys, and is operable at scale.

Design (core idea)- Use a ring-based consistent hash (or rendezvous hashing as an alternative). Map both nodes and keys to a 0..2^32 space; a key is served by the first node clockwise.Minimize remapping- Consistent hashing property: when a node is added/removed only keys that mapped to that node (or its neighbors) move.- Use virtual nodes (vnodes): give each physical server many vnode tokens on the ring to evenly spread ownership; reduces variance and therefore the amount of movement on topology changes.Virtual nodes- Assign 100–1000 vnodes per physical node depending on cluster size and heterogeneity.- When scaling, add/remove vnodes gradually and update routing tables; rebalance by transferring ownership for only affected tokens.Replication & fault tolerance- Replicate by taking the next R distinct physical nodes clockwise from the primary vnode (skip replicas on same host/az). This gives R failure tolerance and allows read-from-secondaries if desired.- Keep per-replica metadata (version, TTL) and use vector clocks or monotonically increasing version for writes to resolve races.Hot-key detection & handling- Monitor per-key QPS and latency; maintain a sliding-window counter or use sketches (Count-Min) to detect heavy hitters.- Mitigation strategies: - Client-side caching / local LRU for very hot keys. - Use special hotspot routing: pin hot key to multiple dedicated shards (materialized replication) or a small in-memory shard group. - Rate-limit or back-pressure write-heavy keys. - Cache-aside pre-warming and TTL tuning; consider sharding the value (split large value) or use dedicated cache tier.Operational concerns- Rebalancing: perform incremental reassignments (move vnode ownership in small batches), stream data asynchronously, use consistent hashing to limit affected keyset. Ensure migrations are idempotent and track progress.- Monitoring: expose per-node metrics (QPS, miss/hit ratio, latency, CPU/memory, vnode distribution). Track key distribution entropy and Gini coefficient to detect imbalance.- Failure detection & recovery: health checks + membership service (e.g., Raft/etcd) to coordinate vnode reassignment; graceful drain before decommissioning nodes.- Testing & safety: simulate failures and node joins offline; have throttles for rebalance throughput; circuit breakers for overloaded nodes.Trade-offs- Rendezvous hashing simplifies vnode handling and gives minimal remap with fewer tokens, but ring+vnodes is easier to stream data.- More replicas increase durability but raise write amplification and consistency complexity. Choose replication factor and read/write quorums per SLA.

This design balances low remapping, even distribution (via vnodes), fault tolerance (replication), and operational practicability (incremental rebalances, monitoring, hotspot mitigation).

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.