Evaluates a candidate's ability to reason about high level system architecture, component interactions, and integration patterns used to build production services. Candidates should be able to visualize major components and the flow of requests and data between them, and to explain client server models, multi tier layered architecture, routing from ingress through load balancing to auto scaled compute instances, and trade offs between monolithic and microservice approaches. Expect discussion of service boundaries and loose coupling; synchronous application programming interfaces and asynchronous messaging; event driven and publish and subscribe architectures; message queues, retry and backoff patterns; caching strategies; and approaches to data consistency and state management. Integration concerns include application programming interfaces, adapters and connectors, extract transform load processes, data synchronization, data warehousing, and the trade offs between real time streaming and batch processing and single source of truth. Candidates should reason about scalability, reliability, availability, redundancy, failover, fault tolerance, latency and throughput trade offs, security boundaries, and common failure modes and bottlenecks. They should also address operational considerations such as monitoring, logging, observability, deployment implications and run books, and explain how architectural choices influence team boundaries, delivery timelines, dependency complexity, testing strategy, maintainability, and operability. Answers should demonstrate clear explanation of design decisions and trade offs without requiring low level implementation detail, and the ability to communicate architecture to both technical and non technical audiences.
EasyTechnical
32 practiced
Explain how load balancing works and the difference between layer 4 (transport) and layer 7 (application) load balancers. Discuss session affinity (sticky sessions), its impact on scaling and state management, and alternative strategies to manage user session state without affinity.
Sample Answer
Load balancing distributes incoming requests across multiple backend servers to improve availability, throughput and latency. A load balancer can operate at different OSI layers:- Layer 4 (transport): routes based on IP and TCP/UDP ports. It forwards packets without inspecting HTTP content, so it’s fast and protocol-agnostic (e.g., TCP load balancing, NAT). Decisions are made using algorithms like round-robin, least-connections, or hashing on IP/port.- Layer 7 (application): understands HTTP(S) and can route based on URL, headers, cookies, or payload. Enables smarter routing (A/B, path-based, host-based, rewriting, WAF).Session affinity (sticky sessions) pins a client to the same backend (via cookie, source IP, or load-balancer state). Pros: simple for stateful apps. Cons: uneven load distribution, harder scaling, single-server failure impacts sessions, and complicates autoscaling.Alternatives to affinity:- Externalize session state: centralized session store (Redis, Memcached) accessible by all app instances.- Client-side tokens: JWTs contain session data signed by server—stateless and scalable.- Database-backed sessions: persist minimal state in DB.- Session replication: replicate sessions across nodes (more complexity/overhead).- Design stateless services: store state in services (S3, DB) and make app instances interchangeable.Best practice: prefer stateless services or centralized session stores for horizontal scalability; use affinity only when necessary for low-latency session-local state.
EasyTechnical
37 practiced
Explain 'eventual consistency' versus 'strong consistency'. Provide concrete examples of systems where eventual consistency is acceptable and where it is not, and describe techniques to mitigate user-visible anomalies like stale reads or lost updates.
Sample Answer
Strong consistency means after a write completes, any subsequent read returns that value — the system behaves like a single up-to-date copy. Eventual consistency means writes will propagate asynchronously: if no new writes occur, all replicas converge to the same value eventually, but intermediate reads can be stale.Examples:- Acceptable: social feeds, analytics counters, DNS, caching layers — occasional staleness is tolerable and you gain latency/availability.- Not acceptable: bank transfers, inventory decrements during checkout, user authentication — correctness and immediate visibility are required.Mitigations for user-visible anomalies:- Read-your-writes / session consistency: route a client to the replica that saw its writes or use client-side sticky sessions.- Quorum reads/writes: require majority ack (e.g., R+W>N) to reduce staleness.- Versioning/conflict resolution: use vector clocks, CRDTs, or application logic to merge concurrent updates safely instead of blind last-write-wins.- Optimistic concurrency: CAS/ETags to prevent lost updates; surface conflicts to user when needed.- Read repair and background anti-entropy to speed convergence.- UX techniques: show “last updated” timestamps, optimistic UI with rollback on conflict, disable risky actions until strong confirmation.Trade-offs: stronger guarantees increase latency and reduce availability under partition; choose consistency level by data criticality and user expectations.
MediumTechnical
59 practiced
Compare distributed transaction patterns: two-phase commit (2PC) and the Saga pattern. Explain how each approach handles atomicity, availability, and isolation, and describe the kinds of business workflows where Sagas are preferred over 2PC.
Sample Answer
Brief definitions:- Two-Phase Commit (2PC): a coordinator-driven protocol that ensures distributed atomic commit by preparing participants, then committing/aborting in a coordinated second phase.- Saga: a long-running transaction split into a sequence of local transactions; each step has a compensating transaction to undo it if later steps fail.Atomicity:- 2PC: Provides strong atomicity (all-or-nothing) across participants if coordinator and participants are reliable.- Saga: Provides eventual/business-level atomicity via compensations—no single ACID atomic commit; correctness depends on compensating logic.Availability:- 2PC: Can block resources while waiting for coordinator/participants (blocking protocol). Coordinator failure reduces availability unless using 3PC or heuristics.- Saga: Higher availability — local transactions commit immediately, system continues even if other services fail; retries and compensations occur asynchronously.Isolation:- 2PC: Can preserve stronger isolation if combined with distributed locking; holds locks across phases, increasing contention.- Saga: Lower isolation; since steps commit independently, other transactions may see intermediate states. Must design idempotency and compensation to handle anomalies.When to prefer Sagas:- Long-running business workflows (order processing, travel bookings, microservices orchestration) where steps are naturally reversible or compensable, low-latency and high-availability are required, and strict global ACID is unnecessary.When to prefer 2PC:- Short, tightly-coupled financial transfers requiring strict atomicity and isolation, where blocking is acceptable and participants support the protocol.Trade-offs summary:- 2PC: strong atomicity/isolation, poorer availability and scalability.- Saga: better availability and scalability, needs careful compensation, and weaker isolation guarantees.
MediumSystem Design
43 practiced
Design a scalable file upload architecture for user-submitted media (images and videos). Requirements: support large files, resumable uploads, virus scanning, thumbnail/transcode processing, durable storage, and near-real-time availability for web clients. Describe ingestion, processing pipeline, retries, and how you would scale each component.
Sample Answer
Requirements (clarified):- Accept large files (multi-GB), resumable uploads, low-latency availability for web clients, durable storage, virus scanning, thumbnailing/transcoding, retries, horizontally scalable.High-level flow:1. Client → Upload Gateway (signed URL + resumable session) → Object Storage2. Event Notification → Message Queue → Processing Workers (virus scan → metadata store → transcode/thumbnail) → CDN + metadata update3. Client polls / websocket for near-real-time statusIngestion:- Use a small Upload Gateway service that authenticates, issues time-limited signed URLs (S3/MinIO presigned PUT) and a resumable upload session ID (tus-protocol or multipart with checkpoints).- Clients upload directly to object storage to offload bandwidth from app servers; store upload manifest in a DB (upload id, chunks, status).Resumability:- Use chunked uploads with checksums; client retries failed chunk uploads; server-side assembly triggered when manifest marks complete.Processing pipeline:- On finalization, emit message to durable queue (Kafka/SQS).- Worker 1: Virus scanning (e.g., ClamAV or cloud malware scanning) runs on the object directly (scan container mounts object or streams from storage). If infected: mark status, move to quarantine, notify user.- Worker 2: If clean, generate thumbnails (images) and transcode (videos) via scalable worker pool (Kubernetes autoscaled jobs or serverless functions for small files). Use GPU instances for heavy transcodes.- Each processing step writes artifacts back to storage (separate buckets/prefixes), updates metadata DB (status, URLs, versions), and emits events.Near-real-time availability:- Expose low-res/placeholder thumbnail immediately after thumbnail job completes. Use CDN in front of storage; invalidate or update CDN on new artifact upload.- Use WebSocket/event stream or pub/sub to notify clients of status changes.Retries and error handling:- Use durable queue with DLQ for poisoned messages.- Workers implement idempotency (process by object version or checksum) and exponential backoff retries.- Track retry counts in message metadata; after N failures alert SRE and mark for manual review.Durability and consistency:- Store originals in immutable, versioned object storage with lifecycle policies; keep metadata in transactional DB (Postgres/DynamoDB) with indices for queries.- Use eventual consistency for processed artifacts; clients read metadata first, then fetch artifact URLs.Scaling each component:- Upload Gateway: stateless, autoscale behind LB; minimal CPU.- Object Storage: use managed S3 or scaled MinIO cluster with erasure coding.- Queue: Kafka/SQS for high throughput and retention.- Workers: Kubernetes Horizontal Pod Autoscaler based on queue depth and CPU; separate worker pools for scanning vs. heavy transcode; use spot/preemptible for cost with fallback on on-demand for reliability.- CDN: edge caching for low latency.Security:- Signed URLs with short TTL, least-privilege IAM roles for workers, server-side encryption, scanning before public availability, audit logs.Trade-offs:- Direct-to-storage reduces app bandwidth but requires careful resumable implementation.- Serverless speeds up small-file processing; heavy video transcodes benefit from dedicated GPU instances.Metrics and Observability:- Track upload success rate, scan failures, processing latency, queue depth, worker error rates; alerts on DLQ growth and SLO breaches.
MediumSystem Design
37 practiced
Design a real-time notifications service that delivers push notifications to mobile devices, websocket updates to web clients, and falls back to email when the user is offline. Requirements: low latency for active sessions, deduplication across channels, per-user rate limits, and reliable delivery with retries.
Sample Answer
Requirements (clarify):- Functional: push to mobile (APNs/FCM), websocket updates to web, email fallback.- Non-functional: low latency for active sessions (<100–200ms path), dedup across channels, per-user rate limits, reliable delivery with retries and at-least-once semantics.High-level architecture:Client apps (mobile, web) ↔ Ingress API (REST/gRPC) → Router/Dispatcher → Delivery Workers → Channel Integrations (APNs/FCM, WebSocket gateway, SMTP service) ← Persistence/Messaging (Kafka) and Supporting services: User Presence, Dedup store, Rate limiter, Retry/Dead-letter store, Metrics.Core components:1. Ingress API: accept notification requests (from app servers/PM), validate, enrich, write to Kafka topic partitioned by user-id for ordering.2. User Presence Service: tracks active sessions (websocket connections, mobile foreground) via heartbeat and stores session metadata in Redis.3. Router/Dispatcher: consumes Kafka, queries Presence and Rate Limiter, decides channel priority (websocket if active, else push, else email), writes delivery task to Delivery Workers.4. Delivery Workers: - WebSocket gateway: deliver to connection pool via clustered gateway (e.g., scalable websocket servers behind LB). - Push workers: batch/aggregate for APNs/FCM, manage token lifecycle. - Email worker: SMTP/SES integration. Each worker writes success/failure to persistence and publishes acknowledgement events for dedup logic.5. Dedup store: short TTL store (Redis with unique key: user:notification:content-hash) to suppress duplicates across channels.6. Rate Limiter: token-bucket per-user in Redis; Router enforces limits, queues or drops low priority notifications.7. Retry & Reliability: failed deliveries are retried with exponential backoff; persistent tasks in durable store; failed after max attempts → dead-letter queue and optional email fallback.8. Observability: metrics, tracing, and dashboards for latency, delivery rates, and errors.Data flow (example):1. Producer posts notification → Kafka.2. Router consumes → checks presence and rate limits.3. If websocket active and dedup not set → send via WebSocket Worker → on success mark dedup key; else attempt push; if offline and push fails (or device token invalid) → send email.Scalability & performance:- Kafka partitions by user-id for ordering and scale.- Redis clusters for presence, dedup, and rate limits with sharding.- WebSocket gateways behind LB with sticky sessions or session-store in Redis.- Push workers use batching to improve throughput.- Autoscale workers based on queue lag and SLOs.Deduplication strategy:- Compute content-hash + notification-type + user-id. Use Redis SETNX with TTL (short window, e.g., 5–60s) to atomically ensure one delivery across channels. Router honors the flag.Per-user rate-limits:- Token-bucket in Redis; Router checks and decrements atomically; if exhausted, either queue to per-user low-priority queue or drop with logged metric.Reliability & retries:- Use durable queues (Kafka + task store).- Retry with exponential backoff and capped attempts; on permanent failures move to DLQ and optionally send summary email.- Idempotency: workers use notification-id to avoid duplicate sends.Trade-offs:- Strong ordering per-user achieved via Kafka partitioning; increases hot-partition risk for very active users — mitigate by further sharding by user segments.- Dedup TTL window trades memory for dedup effectiveness; longer TTL prevents repeats but may suppress legitimate re-sends.- At-least-once delivery simplifies retries but requires idempotent channel clients.Security and privacy:- Encrypt messages at rest, use auth between services, respect user notification preferences and GDPR (opt-outs).This design delivers low-latency for active sessions (direct websocket path), deduplicates across channels, enforces per-user quotas, and provides reliable delivery with retry and DLQ handling.
Unlock Full Question Bank
Get access to hundreds of System Architecture and Integration interview questions and detailed answers.
