Distributed-Systems

Overview Strong and eventual consistency describe how distributed systems handle replicated data after a write. Strong consistency guarantees every read reflects the latest write by blocking until replicas agree, while eventual consistency returns immediately and lets replicas converge in the background. The choice trades write latency and availability against read freshness. Comparison Diagram Strong ConsistencyEventual ConsistencyClientPrimaryReplica 1Replica 2write blocks untilall replicas ackAny read, any replica,always returns latest valueClientNodeReplica 1Replica 2ACK immediateasync, delayedRead from Replica 1 mayreturn stale value until t+Δ Comparison Table Aspect Strong Consistency Eventual Consistency Write acknowledgment Ack returned only after write is durably applied to all (or a quorum of) replicas Ack returned as soon as the write hits the local/primary node Replication propagation Synchronous — write blocks until replicas confirm Asynchronous — replication happens in the background Read guarantee Every read reflects the most recent write (linearizable) Reads may return stale data until replicas converge Conflict handling Prevented upfront via consensus/locking that serializes writes Resolved after the fact via LWW, vector clocks, or CRDTs Write latency Higher — pays network round-trip cost to replicas/quorum Lower — commits locally before propagating Behavior under partition Unavailable or degraded if quorum can’t be reached (CP) Stays available, serving from whichever replica is reachable (AP) Typical mechanism Consensus protocols like Paxos/Raft, synchronous quorum writes Gossip protocols, anti-entropy repair, background sync Typical use cases Banking ledgers, inventory counts, leader election Social feeds, DNS, shopping carts, CDN caches Key Differences Strong consistency blocks the write until a quorum confirms; eventual consistency acks after a local commit. This is the classic CAP tradeoff: strong favors consistency during a partition, eventual favors availability. Strong relies on consensus protocols like Raft; eventual relies on background anti-entropy repair. Only strong consistency guarantees read-after-write; eventual consistency allows a stale-read window. When to Use Each Strong Consistency ...

Overview When a distributed system suffers a network partition, it must choose between consistency (every node sees the same data, even if that means rejecting requests) and availability (every request gets a response, even if the data might be stale). This CAP theorem tradeoff shapes how databases behave under failure and directly affects correctness guarantees versus uptime. Comparison Diagram Consistency (CP)Availability (AP)ClientClient503 blocked200 OK (stale)Node ANode BpartitionNode ANode BpartitionWaits for quorum, rejects requestGuarantee: no stale readsAnswers immediately from local dataGuarantee: no downtime Comparison Table Aspect Consistency (CP) Availability (AP) Normal operation (no partition) Behaves identically to any healthy cluster; all replicas agree Behaves identically to any healthy cluster; all replicas agree Behavior when a partition occurs Nodes that cannot confirm quorum stop responding All nodes keep responding regardless of quorum status Write handling during partition Writes are rejected or queued until enough replicas are reachable Writes are accepted locally and replicated once the partition heals Read handling during partition Reads are blocked or errored if the latest value can’t be confirmed Reads are served from whatever local replica is reachable, even if stale Client-facing failure mode Client sees a timeout or explicit error (e.g. 503) Client sees a successful response that may contain outdated data Data guarantee provided Linearizability - no two nodes ever disagree on current state Liveness - the system always answers, correctness may lag Recovery after partition heals Resumes cleanly; no conflicting writes existed since they were blocked Must reconcile diverging writes via vector clocks, LWW, or CRDTs Representative systems HBase, Zookeeper, MongoDB (default majority writes) Cassandra, DynamoDB, Riak Key Differences The tradeoff only bites during an actual network partition - outside of that, both behave the same. Consistency requires a quorum agreement before answering, which can mean refusing requests. Availability guarantees a response but risks returning stale data to the client. The choice determines whether you need a conflict resolution strategy for divergent writes after recovery. Many production databases offer tunable consistency, letting you pick per-operation rather than a single global stance. When to Use Each Consistency (CP) ...

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 SOA and microservices are both approaches to composing systems from independently callable services, but they differ sharply in scope and philosophy. SOA centralizes communication and governance through an enterprise service bus to integrate large, often legacy systems, while microservices decentralize communication, data, and deployment into small, independently shippable units. The distinction matters because it drives very different tooling, team structures, and failure characteristics. Comparison Diagram SOAMicroservicesS1S2S3S4ESBShared DBCentral bus + shared dataM1M2M3M4dbdbdbdbDirect calls, DB per service Comparison Table Aspect SOA Microservices Communication mechanism Services talk through a central Enterprise Service Bus using protocols like SOAP/WS-* Services talk directly via lightweight REST/gRPC calls or message brokers, no mandatory central bus Service granularity Coarse-grained, often modeling whole business processes Fine-grained, each service owns a single business capability Data ownership Services frequently share a common database or canonical data model Each service owns and manages its own private database Deployment unit Services often share application servers or deployment packages Each service is deployed and scaled independently, typically in its own container Technology stack Standardized enterprise-wide on common platforms and protocols Polyglot — each team chooses its own language, framework, and datastore Fault isolation The ESB is a potential single point of failure affecting many services Failures are isolated to individual services, limiting blast radius Governance & teams Centralized architecture review board and IT governance Decentralized ownership by small, autonomous teams per service Typical origin Emerged from large-scale enterprise integration needs in the 2000s Emerged from cloud-native, DevOps-driven practices in the 2010s Key Differences SOA centralizes routing and transformation logic in an ESB, while microservices push that logic into the endpoints themselves. Microservices mandate database per service, whereas SOA services commonly share a data layer. SOA favors reusable coarse-grained services across the enterprise; microservices favor small, single-purpose services. Microservices deploy and scale via independent containers, while SOA services often share application servers. SOA relies on heavyweight standards like SOAP/WS-*; microservices typically use lightweight REST or gRPC. When to Use Each SOA ...

Overview Client-Server and peer-to-peer describe who talks to whom on a network: one funnels every request through a central server, the other lets nodes exchange data directly as equal peers. The choice shapes scalability, fault tolerance, and who ultimately controls the data. Comparison Diagram Client-ServerPeer-to-PeerServerCCCAll requests routed through serverPPPPPPeers connect directly to each other Comparison Table Aspect Client-Server Peer-to-Peer Node roles Clients and servers have fixed, asymmetric roles Every node acts as both client and server (servent) Connection establishment Clients connect to a known server address (DNS/IP) Nodes discover peers via bootstrap lists, DHTs, or trackers Request handling Server processes and responds to each client request Any peer can serve or request data from any other peer Resource provisioning Server owns the compute, storage, and bandwidth Resources are contributed and shared across participating peers Scalability pattern Scaling requires adding server capacity or replicas Scaling often improves as more peers join and share load Fault tolerance Server outage disrupts all clients (single point of failure) Network tolerates individual peer failures; no single point of failure Security & trust Trust is centralized; server enforces auth and access control Trust is distributed; peers must verify each other independently Typical examples Web apps, REST APIs, email, banking systems BitTorrent, blockchain networks, LAN gaming Key Differences Client-Server relies on a central server as the single source of truth; peer-to-peer distributes data with no authoritative hub. Adding capacity in client-server means scaling the server tier; in peer-to-peer, each new node can add capacity to the network. A server outage is a single point of failure for client-server, while peer-to-peer degrades gracefully as peers leave. Client-server centralizes access control, while peer-to-peer pushes trust and verification onto each peer. When to Use Each Client-Server ...

Overview Synchronous communication is a model where the caller sends a request and then blocks, halting its own execution until a response arrives. Asynchronous communication lets the caller fire off a message and continue working immediately, handling the eventual reply through a callback or queue whenever it arrives. The choice shapes latency tolerance, resource usage, failure handling, and how tightly services are coupled in time. Comparison Diagram Synchronous Asynchronous Caller Service request blocked processing response resumes Caller Service send other work processing callback / event handle reply time Comparison Table Aspect Synchronous Asynchronous Call initiation Caller sends request and immediately waits for it to complete Caller sends a message and continues its own execution right away Execution model Caller thread blocks until the response returns inline Caller thread is free; response is handled via callback, event, or poll later Coupling in time Both sender and receiver must be available and reachable at the same moment Sender and receiver need not be online simultaneously; a broker bridges the gap Response delivery Direct return value over the same connection used for the request Message queue, event bus, webhook, or polling delivers the result separately Failure handling Failure surfaces immediately to the caller as an exception or timeout Failure is detected later via retries, dead-letter queues, or timeout callbacks Ordering & concurrency One call in flight per thread, so ordering is implicit and easy to reason about Many calls can be in flight concurrently, so ordering must be handled explicitly Resource usage Thread and connection are held open for the full duration of the call Thread is released immediately; resources are consumed only during actual processing Typical transport REST/HTTP request-response, gRPC unary calls, direct RPC Message queues (Kafka, RabbitMQ, SQS), event streams, webhooks Key Differences Synchronous callers block until a response returns; asynchronous callers proceed without waiting. Synchronous ties sender and receiver together in time; asynchronous decouples them through a broker or queue. Synchronous failures surface immediately as timeouts or exceptions; asynchronous failures often need dead-letter handling or retries. Synchronous holds a thread or connection open for the call’s duration; asynchronous frees the caller, trading immediacy for throughput. When to Use Each Synchronous ...

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 Monitoring watches a predefined set of metrics, logs, and checks against known failure modes and alerts you when thresholds are breached. Observability is a property of a system built so that its internal state can be inferred from its external outputs, letting you investigate questions you didn’t think to ask in advance. The distinction matters because monitoring answers ‘is something wrong?’ while observability answers ‘why is it wrong?’ for failures you’ve never seen before. ...

Overview Failover and fallback both describe what a system does when something breaks, but they differ in what changes. Failover swaps a failed component for an identical redundant one so behavior stays the same, while fallback switches to a different, usually simpler or lower-fidelity path when the preferred one is unavailable. Confusing the two leads to designs that promise seamless continuity but actually degrade functionality, or vice versa. Comparison Diagram FailoverFallbackClientPrimary (Active)same behaviorStandby (identical)takes over, same outputredundant component, unchanged functionClientPrimary Pathfull behaviorFallback (degraded/default)reduced or cached responsealternate path, changed function Comparison Table Aspect Failover Fallback Core action Switch to a redundant, identical component Switch to a different, usually simpler alternative Functional parity Preserves full functionality and quality Often reduced functionality, accuracy, or freshness Typical scope Infrastructure/system level (servers, nodes, DCs) Application/logic level (methods, values, services) Trigger Health check or heartbeat failure detection Exception, timeout, cache miss, or unmet condition Example Active database node dies; standby replica takes over queries transparently Live pricing API call fails; app falls back to last cached price Recovery expectation Usually paired with failback once primary recovers Often stays on fallback until explicitly retried or root cause fixed User-visible impact Ideally none, if failover is seamless Often visible as a lower-quality or generic result Design goal High availability / continuity of service Graceful degradation / resilience of a single call or feature Key Differences Failover replaces a broken component with an equivalent one; fallback replaces a preferred behavior with a lesser one. Failover targets infrastructure-level continuity (nodes, clusters, regions); fallback targets code-level resilience (a single function or request). Failover implies redundancy of identical capability; fallback implies acceptance of reduced capability. Failover is often followed by ‘failback’ to the restored primary; fallback usually persists until the underlying issue is resolved or retried. A system can use both together: infrastructure fails over to a standby, while an individual call within that system falls back to cached data. When to Use Each Failover ...