System-Design

Overview Batch processing collects data over a period and runs computation on the whole bounded set at once, while stream processing handles each event as it arrives, continuously. The choice determines whether your system optimizes for throughput and simplicity or low latency on fresh results. Comparison Diagram BatchStreamData accumulatesinto a bounded setScheduled jobprocesses all at onceResult: high latencyEvents flow continuouslyprocessprocessprocessprocessResult: low latency Comparison Table Aspect Batch Processing Stream Processing Data ingestion Data collected and stored until job triggers Events consumed individually as they arrive Data scope per run Bounded, finite dataset (a file, a partition, a day’s data) Unbounded, continuous sequence of events Processing trigger Scheduled interval or manual kickoff (hourly, nightly) Continuous, triggered by each event or micro-window Latency to result Minutes to hours, depending on schedule Milliseconds to seconds State management Recomputed fresh from full dataset each run Maintained incrementally across the event stream Fault recovery Rerun the failed job against the same input Checkpointing and replay from an offset in the log Ordering guarantees Whole dataset available, so ordering enforced within the job Ordering must be explicitly handled (per-key, watermarks) Resource usage pattern Spiky: idle, then a burst of compute at run time Steady, sustained compute and memory footprint Key Differences Batch operates on a bounded dataset, stream operates on an unbounded sequence of events Batch trades latency for simplicity and throughput; stream trades complexity for freshness Stream systems need watermarks to handle late or out-of-order events, which batch avoids entirely Failure recovery in batch means rerunning the job; stream relies on checkpoint and replay semantics Batch pipelines are easier to reason about and test since input is fixed and reproducible When to Use Each Batch Processing ...

Overview A single model uses one unified set of classes and one schema for both reading and writing data, while CQRS (Command Query Responsibility Segregation) splits the system into separate write models (commands) and read models (queries) that can use different schemas, storage, or even databases. The choice matters because it trades simplicity and consistency for scalability and query flexibility as read and write demands diverge. Comparison Diagram Single ModelCQRSRead ReqWrite ReqModelreads + writesOne DB / SchemaQueryCommandRead Modeloptimized viewWrite Modeldomain logicRead StoreWrite Storesync / events Comparison Table Aspect Single Model CQRS Request entry point One API/service handles reads and writes through the same code path Requests are split upfront into command handlers and query handlers Data model shape One set of classes/entities represents the domain for every operation Separate write model (rich domain logic) and read model (denormalized, query-optimized) Write path Write validates and persists directly to the shared schema Command handler validates, applies business rules, persists to the write store Read path Read queries the same schema writes use, often requiring joins Query handler reads from a precomputed, often denormalized read store Sync between models Not applicable — there is only one model, so no sync is needed Read store is updated via events or projections after each write, introducing lag Consistency guarantee Strong consistency by default since reads see writes immediately Eventual consistency between write and read sides unless engineered otherwise Scaling behavior Read and write load scale together since they share infrastructure Read and write sides scale independently to match different load profiles Operational complexity Low — one schema, one deployment, one mental model to maintain Higher — multiple stores, projection/event pipelines, and eventual-consistency debugging Key Differences Single model keeps one schema for everything; CQRS splits into a write model and a read model CQRS trades immediate consistency for eventual consistency via projections or events Single model is simpler to reason about; CQRS adds operational overhead from syncing multiple stores CQRS enables independent scaling of reads and writes; single model scales them together Query flexibility is higher in CQRS since read models can be shaped per use case When to Use Each Single Model ...

Overview This comparison covers whether a server or protocol retains session state between requests, or treats every request as a fully self-contained unit with no memory of prior ones. The choice determines how you scale, fail over, and route traffic across instances. Comparison Diagram StatefulStatelessClientServer Asession: id=42must returnto same serverServer Bno session dataClientcarries tokenServerServerany server canhandle the requestStateful: server pins session context and routing depends on itStateless: request carries all context, any node can serve it Comparison Table Aspect Stateful Stateless Request context Server retains prior interaction data across requests Each request carries all context needed to process it Session storage Held in server memory or local session store None on server; state lives in client token or database Routing requirement Requests must reach the same server (sticky sessions) Any server instance can handle any request Scaling model Vertical or sticky-session horizontal scaling only Trivial horizontal scaling, load balance freely Failure recovery Server crash loses in-memory session unless replicated Server crash has no session impact, retry hits any node Client design Client can be thin, server tracks progress Client or token must resend full context each call Typical examples Database connections, WebSocket sessions, FTP REST APIs, HTTP with JWT, DNS lookups Key Differences Stateful servers keep session memory; stateless servers keep none between calls Stateless systems need no sticky routing, simplifying load balancers Stateful failover requires session replication to avoid data loss Stateless designs push state into the client or token instead of the server Horizontal scaling is near-free for stateless architectures When to Use Each Stateful ...

Overview A monolith packages an application’s entire codebase and functionality into a single deployable unit running as one process, while microservices split that same functionality into independently deployable services that communicate over a network. The choice shapes how teams build, deploy, scale, and recover from failures, so it matters far beyond just code organization. Comparison Diagram MonolithAuthOrdersInventoryPaymentsSingle processSingle deployMicroservicesAPI GatewayAuthOrdersInventoryPaymentsseparate databasesIndependent servicesIndependent deploys Comparison Table Aspect Monolith Microservices Codebase structure Single repository, one shared codebase for all functionality Multiple repositories, one per service with its own codebase Deployment unit Whole application built and shipped as one artifact Each service built, versioned, and shipped independently Inter-module communication In-process function calls within the same runtime Network calls via HTTP, gRPC, or messaging between services Data storage Typically one shared database for the whole app Each service usually owns its own database or schema Scaling Scale the entire application even if only one part is hot Scale only the specific services that need more capacity Fault isolation A crash or memory leak in one module can take down the app A failing service degrades its own function without necessarily crashing others Technology stack One language and framework across the whole application Each service can use the language/framework best suited to it Team ownership and releases One team or a coordinated release train ships the whole app together Independent teams own and release their services on their own schedules Key Differences A monolith runs as a single process, while microservices are distributed processes talking over the network Microservices trade in-process call reliability for network latency and partial failure handling Independent deployability lets microservices teams ship on separate release cadences, which a monolith can’t offer Splitting services adds real operational overhead — service discovery, monitoring, and distributed tracing Data ownership per service enables polyglot persistence but sacrifices easy cross-entity transactions When to Use Each Monolith ...

Overview Vertical scaling grows capacity by adding more CPU/RAM to a single machine, while horizontal scaling grows capacity by adding more nodes behind a load balancer. The choice shapes your application’s architecture, failure model, and cost curve as it grows. Comparison Diagram VerticalHorizontalServerServer+CPU +RAMServer++CPU ++RAMLoad BalancerNodeNodeNode+NodeSingle node, growingMany nodes, distributed Comparison Table Aspect Vertical Scaling Horizontal Scaling Scaling mechanism Add CPU, RAM, or faster disks to one machine Add more machines/nodes to a shared pool Architecture requirement Works with any app, no code changes needed Requires stateless design, load balancing, and shared state (session store, distributed cache) Upper limit Capped by the largest hardware SKU available Effectively unbounded, limited only by orchestration and cost Downtime during scale-up Often requires reboot or migration to bigger instance New nodes join the pool live, no downtime Fault tolerance Single point of failure — one box, one crash Node failures are absorbed by the remaining pool Cost curve Price rises non-linearly at the high end (diminishing returns) Roughly linear cost per added unit of capacity Operational complexity Low — one server to patch, monitor, and secure Higher — needs service discovery, distributed monitoring, data consistency handling Typical use case Monolithic apps, relational databases, legacy systems Stateless web services, microservices, cloud-native workloads Key Differences Vertical scaling upgrades a single machine; horizontal scaling adds more machines to a pool Horizontal scaling demands stateless services, while vertical scaling needs no architectural change Vertical scaling has a hard hardware ceiling; horizontal scaling scales near-linearly A single oversized server is a single point of failure, unlike a distributed node pool Horizontal scaling trades simplicity for operational complexity in orchestration and consistency When to Use Each Vertical Scaling ...

Overview Push and pull architecture describe who initiates data transfer between a producer and a consumer: in a push model the producer sends data the moment it’s ready, while in a pull model the consumer requests data on its own schedule. The choice shapes latency, coupling, and how systems handle scale or downtime. Comparison Diagram PUSH(producer-initiated)ProducerConsumerdata pushedPULL(consumer-initiated)ConsumerProducerrequestresponse Comparison Table Aspect Push Pull Initiator of transfer Producer sends data as soon as it’s available Consumer requests data on its own schedule Data freshness Near-real-time; consumer receives updates immediately Bounded by poll interval; can lag between requests Consumer control Producer dictates pace; consumer must keep up Consumer sets pace and can throttle or batch requests Coupling Producer must track and address its consumers Producer stays unaware of who is asking Scalability with consumers Fan-out cost grows with each new subscriber Each consumer’s load stays independent of the others Offline or slow consumers Missed pushes risk data loss without a buffer or queue Consumer simply polls again later, no data lost Idle resource usage Zero overhead when there is nothing new to send Wastes cycles and requests polling when nothing changed Typical examples Webhooks, WebSockets, pub/sub message brokers REST polling, cron jobs, RSS feed readers Key Differences Push delivers data the instant it’s produced, minimizing latency at the cost of straining consumer readiness. Pull lets the consumer control pacing, avoiding overload but risking staleness between requests. Push requires the producer to maintain a subscriber list, increasing coupling and fan-out complexity. Pull wastes cycles on empty polls when nothing has changed since the last request. Push needs a buffering or queueing layer to survive consumer downtime without losing data. When to Use Each Push ...

Overview This comparison covers how servers handle client context across requests: a stateless server treats every request as self-contained with no memory of what came before, while a stateful server keeps track of session data tied to a specific client across multiple requests. The choice shapes how easily a system scales, recovers from failure, and routes traffic under load. Comparison Diagram StatelessStatefulClientLoadBalancerServer AServer BServer Cany server can handle any requestno session stored server-sideClientServer+ SessionstickyServerServermust always return tosame server holding session Comparison Table Aspect Stateless Stateful Request self-sufficiency Each request carries all data needed to process it, independent of prior requests Each request depends on context accumulated from prior requests in the same session State storage location Held externally (client token, database, cache) or not persisted at all Held in server memory or local storage tied to a specific server instance Load balancing Any available server can handle any request; simple round-robin routing Requests must be routed to the specific server holding the session (sticky sessions) Horizontal scaling Add or remove server instances freely with no coordination needed Requires state replication or migration before instances can be added or removed Failure recovery A crashed server loses nothing; the next request is simply retried elsewhere A crashed server can drop the active session unless state was replicated Resource footprint per server Lower memory overhead since no per-client data is retained between requests Higher memory/storage overhead from tracking active sessions Typical examples REST APIs, DNS lookups, serverless functions, CDN edge nodes Database connections, WebSocket sessions, FTP, multiplayer game servers Key Differences Stateless servers require no session affinity; stateful servers need sticky routing to reach the same instance. State in stateless systems lives in external stores or the client; state in stateful systems lives in server memory. Stateless architectures scale horizontally with ease, while stateful ones need state replication to scale out. A crashed stateless server loses nothing, but a crashed stateful server can drop an active session. When to Use Each Stateless ...

Overview Monolithic architecture packages an entire application as a single deployable unit, while microservices architecture splits it into independently deployable distributed services. The choice shapes everything from how teams organize their work to how failures propagate and how the system scales under load. Comparison Diagram Monolith Microservices UI Layer Business Logic Data Access Shared DB single deployable unit API Gateway Orders Users Payments Inventory db db db db independent, own datastores Comparison Table Aspect Monolithic Architecture Microservices Architecture Deployment unit Single deployable artifact containing all modules Multiple independently deployable services Inter-component communication In-process function calls Network calls (REST, gRPC, or messaging) Data storage Typically one shared database Each service owns and manages its own database Scaling approach Scale the entire application as one unit Scale individual services independently based on load Fault isolation A bug or crash can bring down the whole application Failures can be isolated to a single service when designed well Release and deployment process Single build/deploy pipeline with coordinated releases Independent CI/CD pipeline per service, deployed on its own schedule Technology stack flexibility One language and framework for the entire app Polyglot — each service can pick its own stack Operational overhead Low — one application to host and monitor High — requires service discovery, orchestration, and distributed tracing Key Differences Monolith code runs as a single process; microservices communicate as independent processes over the network. A monolith centers on one shared database, while microservices decentralize data ownership per service. Microservices allow granular scaling of just the components under load, unlike a monolith that scales as a whole. Splitting into services buys better fault containment but introduces real operational complexity. Well-designed microservices offer stronger fault isolation than a monolith, where one bug can crash everything. When to Use Each Monolithic Architecture ...

Overview Caching strategies differ mainly in who updates the cache and when. Cache-Aside leaves the application responsible for loading data into the cache on a miss and writing straight to the database, while write-through/write-behind caches push writes through the cache itself — synchronously for durability or asynchronously for speed. The choice shapes consistency guarantees, crash-safety, and how much write latency the app absorbs. Comparison Diagram Cache-AsideAppCacheDBreadon miss: fetch + populateWrite-ThroughAppCacheDBwritesync writeWrite-BehindAppCacheDBwrite (fast ack)async flush (delayed) Comparison Table Aspect Cache-Aside Write-Through / Write-Behind Read path App checks the cache first; on a miss, it reads from the DB itself and populates the cache Cache is always kept current on writes, so reads simply hit the cache without app-managed fallback logic Write path App writes directly to the DB; the cache entry is invalidated or left stale until the next read App writes only to the cache; the cache layer propagates the write to the DB itself Write latency perceived by app Only DB write latency, since the cache isn’t touched on write Write-Through waits for both cache and DB commit; Write-Behind returns after the cache write only Consistency between cache and DB Brief staleness window possible between invalidation and the next read Write-Through stays consistent immediately; Write-Behind lags until the queued flush completes Data loss risk on crash None — the DB is always the write target, so a cache crash loses nothing Write-Through has no loss; Write-Behind can lose unflushed writes if the cache crashes before flush Implementation complexity App owns miss handling and invalidation logic explicitly Cache layer owns persistence logic; Write-Behind adds a queue/flush scheduler Typical use case Read-heavy workloads with unpredictable key access, e.g. Redis in front of a relational DB Write-Through suits systems needing instant durability; Write-Behind suits high write-throughput systems tolerant of brief loss, e.g. metrics buffers Key Differences Cache-Aside puts the application in charge of both fetch-on-miss and invalidation, while write-through/write-behind push that responsibility into the cache layer itself Only Write-Behind delivers real write latency savings by acknowledging before the DB commit completes Write-Through guarantees immediate durability at write time, while Write-Behind trades some of that durability for throughput Cache-Aside is the only strategy where a cache outage never risks data loss, since writes never pass through it When to Use Each Cache-Aside ...

Overview Horizontal and vertical scaling are the two fundamental strategies for adding capacity to a system: one adds more nodes working in parallel, the other adds more resources to a single existing node. The choice shapes cost, downtime, fault tolerance, and how much your application architecture has to change to support it. Comparison Diagram Horizontal ScalingVertical ScalingLoad BalancerS1S2S3+scale out: add identical nodesno downtime, redundantServer2 CPU / 4GBSame Server16 CPU / 64GBupgradedscale up: add CPU/RAM/diskoften needs downtime Comparison Table Aspect Horizontal Scaling Vertical Scaling Mechanism Add more machines/nodes to the pool Add more CPU, RAM, or disk to an existing machine Implementation Requires a load balancer and clustering to distribute work Swap hardware or resize the VM/instance in place Downtime Typically none; new nodes join the pool live Usually requires a reboot or maintenance window Application requirements App must be stateless or handle distributed state App can remain unaware, since it still runs on one node Cost model Roughly linear cost per added commodity node Cost rises steeply at high-end hardware tiers Fault tolerance Redundant; a node failing doesn’t take the system down Single point of failure; that node failing is an outage Capacity ceiling Practically unbounded, add nodes as needed Bounded by the largest machine/instance available Typical use case Web-scale services, microservices, cloud-native apps Databases, legacy monoliths, short-term quick fixes Key Differences Horizontal scaling adds more nodes in parallel, while vertical scaling adds more resources to one existing node. Horizontal scaling needs a load balancer and app-level statelessness; vertical scaling needs no architectural change. Vertical scaling eventually hits a hardware ceiling; horizontal scaling can grow near-limitlessly. Vertical scaling usually requires downtime to resize, while horizontal scaling can add capacity live. Horizontal scaling improves fault tolerance through redundancy; vertical scaling keeps a single point of failure. When to Use Each Horizontal Scaling ...