System design
Architecture decisions, distributed systems, and ten design scenarios.
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.