System-Design on IT Comparison

Batch vs Stream Processing: Bounded Data Dumps vs Continuous Event Flow

Sun, 06 Sep 2026 10:02:40 +0900

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

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

Single Model vs CQRS: One Data Model vs Split Read/Write Models

Sun, 06 Sep 2026 09:53:08 +0900

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

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

Stateful vs Stateless: Where the Session Lives

Sun, 06 Sep 2026 09:51:46 +0900

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

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

Monolith vs Microservices: One Deployable vs Many

Sun, 06 Sep 2026 09:51:18 +0900

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

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

Vertical vs Horizontal Scaling: Bigger Box vs More Boxes

Sun, 06 Sep 2026 09:36:59 +0900

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

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

Push vs Pull Architecture: Who Initiates the Data Transfer

Tue, 04 Aug 2026 05:24:00 +0900

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

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

Stateless vs Stateful Architecture: Where Request Context Lives

Tue, 04 Aug 2026 05:18:18 +0900

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

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

Monolith vs Microservices: Architecture Comparison

Tue, 04 Aug 2026 05:06:36 +0900

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

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

Cache-Aside vs Write-Through vs Write-Behind: Caching Strategies Compared

Sun, 02 Aug 2026 23:52:10 +0900

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

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

Horizontal Scaling vs Vertical Scaling: Growing Out vs Growing Up

Sun, 02 Aug 2026 23:47:18 +0900

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

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