Question library
Explained questions for the decisions developers make.
Cache, CDN, replica or shard: which solves what?
Caches, CDNs, replicas and shards address different kinds of repeated work or load. A cache reuses a result, a CDN brings cacheable content closer to users, a replica copies data, and a shard owns a subset of data. Combining them requires freshness, routing and recovery rules rather than simply adding more boxes.
How does cache-aside work?
Cache-aside means the application manages when values enter and leave the cache. It first looks in the cache, loads missing data from the source of truth, then stores that result for later readers. This reduces repeated database work but creates a separate copy whose freshness must be controlled.
What does CAP actually mean?
CAP describes a limit on distributed systems during a network partition. If nodes cannot communicate, the system cannot guarantee both a single up-to-date view of data and a successful response to every request to non-failing nodes. It must sometimes sacrifice availability or allow responses that may not satisfy that consistency guarantee.
What is eventual consistency?
Eventual consistency allows copies or derived views to differ temporarily while updates propagate. If no new changes occur and processing succeeds, those views converge. This is useful when a delay is acceptable, but the product must define what users see during that delay and how failed propagation is repaired.
Queue vs event vs worker?
A queue holds work waiting to be processed, a worker executes that work, and an event describes a fact that already happened. Commands request an action, while events can notify multiple interested consumers. Delivery and acknowledgement rules determine what happens when workers crash or messages are repeated.
How do I design retries and dead-letter handling?
Retries repeat failed work in the hope that a temporary problem has passed. Backoff spreads attempts over time, jitter avoids synchronized retry bursts, and a dead-letter queue stores work that exceeded its retry policy. Without limits, retries can turn a small outage into sustained overload.
What are idempotency and the outbox pattern?
Idempotency makes repeated requests for one logical operation produce one intended effect. The outbox pattern stores an event record in the same database transaction as the business change, allowing a later publisher to send it reliably. These solve related but different failure windows: duplicate work and losing the message between a commit and publication.
How do I handle partial failure across services?
A cross-service workflow can partly succeed because each service commits independently. A saga coordinates local steps and compensating actions to recover when a later step fails. Compensation is a business recovery action, such as refunding a payment, and may not exactly erase every observable effect of the original action.
How would you design a workflow automation platform?
A workflow platform stores a definition of steps and executes separate runs of that definition over time. Because runs can wait, retry or survive a restart, their progress must be durable rather than only held in a process. A queue and worker layer lets execution capacity grow separately from the request API.
How would you design an HR integration platform?
An HR integration platform synchronizes employee-related data between systems that may use different IDs and update rules. Its main difficulty is deciding ownership and resolving partial, delayed or conflicting updates. Provider adapters keep vendor-specific authentication and data formats separate from the internal employee model.
How would you design an investment analytics platform?
An analytics platform turns data from several sources into comparable reports and metrics. Ingestion, normalization and aggregation should be separate enough that a slow provider does not block every report request. Users need to know the source and freshness of a result, especially when one import is incomplete.
How would you design a notification service?
A notification service accepts delivery requests and sends them through channels such as email, SMS or push. Queued delivery separates user-facing request speed from provider latency and limits. Durable status records allow retries, troubleshooting and reporting without assuming that provider acceptance means the user received the message.
How would you design a URL shortener?
A URL shortener maps a compact public code to a destination URL and redirects visitors efficiently. Creation needs unique-code handling, while redirects usually dominate the read workload. Caching can speed up redirects, but expiry, abuse controls and private links influence the cache and access rules.
How would you design a chat system?
A chat service delivers messages to connected users while preserving enough state for offline users and reconnects. Persistent storage provides history, and WebSockets provide timely delivery to active connections. Message IDs, ordering rules and acknowledgements let clients recover without displaying duplicates or losing unseen messages.
How would you design a file processing system?
A file-processing service accepts an upload and transforms it asynchronously, such as extracting data or generating a report. Object storage holds the file, a durable job references it, and workers perform bounded processing. Keeping bytes out of the request server's memory improves stability for large uploads.
How would you design an e-commerce platform?
An e-commerce system coordinates browsing, stock, orders and payments, which have different consistency needs. Catalog reads can often be cached, while stock reservation and order/payment transitions need stronger protection. External payments introduce uncertain outcomes that require durable state and reconciliation.
How would you design a real-time dashboard?
A real-time dashboard presents frequently changing summaries without making each browser recalculate the whole dataset. An ingestion or aggregation layer builds the current view, and SSE or WebSockets deliver relevant updates. Clients still need an initial snapshot and a way to recover missed updates after disconnecting.
How would you design an order-book-like matching system?
An order-book matching service accepts orders and matches eligible buyers and sellers according to explicit market rules. In a simple price/time model, price determines priority first and accepted sequence resolves equal-price competition. Correct ordering, durable records and deterministic recovery matter more than maximizing concurrency within one book.
Difficulty is an editorial estimate. Completion means you chose to mark a question as understood.