<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Vibe Engines — Distributed Systems</title>
    <link>https://vibeengines.com/topic/distributed-systems</link>
    <atom:link href="https://vibeengines.com/topic/distributed-systems/feed.xml" rel="self" type="application/rss+xml" />
    <description>Consistency, consensus, replication and coordination — the CAP-theorem-shaped trade-offs at the heart of every large-scale system — together with the systems foundations underneath them: operating systems, networking, containers and the languages built for this work.</description>
    <language>en</language>
    <lastBuildDate>Tue, 28 Jul 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>Exponential Backoff Calculator</title>
      <link>https://vibeengines.com/tools/exponential-backoff-calculator</link>
      <guid isPermaLink="true">https://vibeengines.com/tools/exponential-backoff-calculator</guid>
      <category>Tool</category>
      <description>An interactive exponential-backoff calculator. Set the base delay, multiplier, cap and retry count, then see the exact delay before every retry attempt, the worst-case total wait, and how full and equal jitter change the numbers — so you can size retries that recover fast without hammering a service that is already struggling.</description>
      <pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Orchestration vs Choreography</title>
      <link>https://vibeengines.com/handbook/orchestration-vs-choreography</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/orchestration-vs-choreography</guid>
      <category>Handbook</category>
      <description>Orchestration vs choreography for coordinating microservices, decided by where control lives: orchestration puts one central coordinator in charge of a workflow; choreography lets services react to events with no central controller. Central visibility vs loose coupling, the saga pattern, and when to use each.</description>
      <pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Optimistic vs Pessimistic Locking</title>
      <link>https://vibeengines.com/handbook/optimistic-vs-pessimistic-locking</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/optimistic-vs-pessimistic-locking</guid>
      <category>Handbook</category>
      <description>Optimistic vs pessimistic locking, decided by how likely two writers collide: pessimistic locks a row before editing so others wait; optimistic edits without a lock and checks a version on write, retrying on conflict. Contention, deadlocks, retry storms, and when each wins.</description>
      <pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>TCP vs UDP</title>
      <link>https://vibeengines.com/handbook/tcp-vs-udp</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/tcp-vs-udp</guid>
      <category>Handbook</category>
      <description>TCP vs UDP, decided by whether every byte must arrive: TCP is connection-oriented and guarantees reliable, in-order delivery with flow and congestion control; UDP is connectionless and fires packets with no guarantees and almost no overhead. Head-of-line blocking, why real-time uses UDP, how QUIC/HTTP-3 gets both, and when each wins.</description>
      <pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Process vs Thread</title>
      <link>https://vibeengines.com/handbook/process-vs-thread</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/process-vs-thread</guid>
      <category>Handbook</category>
      <description>Process vs thread, decided by whether they share memory: a process is an independent program with its own isolated memory; a thread runs inside a process and shares its memory. Isolation and safety vs cheap, fast, shared-memory concurrency — creation and context-switch cost, crash blast radius, the Python GIL, and when to use each.</description>
      <pubDate>Sat, 25 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>GraphQL vs REST</title>
      <link>https://vibeengines.com/handbook/graphql-vs-rest</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/graphql-vs-rest</guid>
      <category>Handbook</category>
      <description>GraphQL vs REST, decided by who chooses the shape of the response: REST exposes many fixed resource URLs and the server decides what each returns; GraphQL exposes one endpoint and the client asks for exactly the fields it needs. Over- and under-fetching, HTTP caching vs the N+1 problem, versioning, and when each wins — plus why &quot;REST services behind a GraphQL gateway&quot; is so common.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design Webhook Ingestion at Scale</title>
      <link>https://vibeengines.com/systemdesign/webhook-ingestion-at-scale-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/webhook-ingestion-at-scale-system-design</guid>
      <category>System Design</category>
      <description>Build a reliable webhook ingestion pipeline — the backbone of every integration. Learn signature verification and replay protection, acknowledging fast with a durable queue, idempotent processing that turns at-least-once delivery into effectively exactly-once, bounded retries with a dead-letter queue, replay after a fix, and monitoring consumer lag and DLQ depth.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Customer Data Integration Pipeline</title>
      <link>https://vibeengines.com/systemdesign/customer-data-integration-pipeline-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/customer-data-integration-pipeline-system-design</guid>
      <category>System Design</category>
      <description>Build the pipeline that ingests a customer’s messy data on almost every deployment. Learn source connectors (API, SFTP, database, change-data-capture), staging, validation and mapping to a canonical schema, quarantining bad rows instead of dropping them, incremental sync by checkpoint, idempotent upsert loads with backfill, and reconciliation that proves the data landed.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design Multi-Tenant Customer Isolation</title>
      <link>https://vibeengines.com/systemdesign/multi-tenant-customer-isolation-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/multi-tenant-customer-isolation-system-design</guid>
      <category>System Design</category>
      <description>Serve many customers from one system without ever leaking data between them. Learn tenant context propagation, the data-isolation spectrum (row-level, schema-per-tenant, database-per-tenant), preventing noisy neighbors with per-tenant quotas, per-tenant encryption keys and config, and audit plus automated cross-tenant tests that make isolation provable.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Consistent Hashing Ring</title>
      <link>https://vibeengines.com/challenge/consistent-hash-ring</link>
      <guid isPermaLink="true">https://vibeengines.com/challenge/consistent-hash-ring</guid>
      <category>Challenge</category>
      <description>How distributed caches decide which node owns a key — with tiny churn when nodes join or leave. Build a hash ring with virtual nodes and route keys clockwise. A provided hash keeps Python and TypeScript in sync. Hidden tests.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Raft Leader Election (Majority)</title>
      <link>https://vibeengines.com/challenge/raft-election-step</link>
      <guid isPermaLink="true">https://vibeengines.com/challenge/raft-election-step</guid>
      <category>Challenge</category>
      <description>The heartbeat of the Raft consensus algorithm: a candidate becomes leader only by winning a strict majority of the cluster — the rule that guarantees at most one leader per term. Decide an election round. Solve it in Python or TypeScript, with hidden tests.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Vector Clock Merge</title>
      <link>https://vibeengines.com/challenge/vector-clock-merge</link>
      <guid isPermaLink="true">https://vibeengines.com/challenge/vector-clock-merge</guid>
      <category>Challenge</category>
      <description>Vector clocks let processes with no shared time agree on which event caused which. The key operation: on receive, take the element-wise max of the two clocks, then tick your own entry. Solve it in Python or TypeScript, with hidden tests.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>CRDT: Grow-Only Counter</title>
      <link>https://vibeengines.com/challenge/crdt-gcounter</link>
      <guid isPermaLink="true">https://vibeengines.com/challenge/crdt-gcounter</guid>
      <category>Challenge</category>
      <description>A counter many replicas increment independently, with no coordination, that always converges to the same total after syncing — a G-Counter, the simplest CRDT. Merge per-replica payloads by element-wise max. Solve it in Python or TypeScript, with hidden tests.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>SRE Roadmap</title>
      <link>https://vibeengines.com/roadmap/sre</link>
      <guid isPermaLink="true">https://vibeengines.com/roadmap/sre</guid>
      <category>Roadmap</category>
      <description>A step-by-step roadmap to become a site reliability engineer in 2026. From Linux, networking and distributed systems through SLOs, error budgets, alerting, incident response and postmortems to reliability patterns, chaos engineering, Kubernetes reliability, automation and disaster recovery. 18 stations across 3 tracks — Foundations, Reliability Practice, Scale &amp; Resilience.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Solutions Architect Roadmap</title>
      <link>https://vibeengines.com/roadmap/solutions-architect</link>
      <guid isPermaLink="true">https://vibeengines.com/roadmap/solutions-architect</guid>
      <category>Roadmap</category>
      <description>A step-by-step roadmap to become a solutions architect in 2026. From cloud fundamentals, networking and data through the Well-Architected pillars, scalability, resilience, cost and integration patterns to requirements discovery, architecture decisions, stakeholder communication and the SA career. 18 stations across 3 tracks — Foundations, Designing Systems, The Craft.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Connection Pool Sizer</title>
      <link>https://vibeengines.com/tools/connection-pool-sizer</link>
      <guid isPermaLink="true">https://vibeengines.com/tools/connection-pool-sizer</guid>
      <category>Tool</category>
      <description>A database connection pool sizer built on Little’s Law. Enter your peak queries per second, average query latency, and how many application instances you run, and get the concurrency you actually need, a per-instance pool size with headroom, and a check against your database’s max-connections limit — so you neither starve requests nor exhaust the database.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Rate Limit Designer</title>
      <link>https://vibeengines.com/tools/rate-limit-designer</link>
      <guid isPermaLink="true">https://vibeengines.com/tools/rate-limit-designer</guid>
      <category>Tool</category>
      <description>A rate limiter designer. Enter the sustained rate you want to allow and how big a burst to tolerate, and get concrete token-bucket parameters (refill rate and capacity), the effective peak burst, and how the choice compares to fixed-window and sliding-window approaches — including the boundary-burst pitfall of fixed windows.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Sharding Planner</title>
      <link>https://vibeengines.com/tools/sharding-planner</link>
      <guid isPermaLink="true">https://vibeengines.com/tools/sharding-planner</guid>
      <category>Tool</category>
      <description>A database sharding planner. Enter your total data size and query rate, and what a single shard can hold and serve, and get the number of shards you need — the larger of the storage and throughput requirements, with growth headroom — plus the per-shard load and a reminder of what resharding later costs.</description>
      <pubDate>Fri, 24 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Raft: The Election</title>
      <link>https://vibeengines.com/lab/raft-simulator</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/raft-simulator</guid>
      <category>Lab</category>
      <description>Don't read about Raft — run the cluster. Five nodes start as followers with random election timers; when one times out it becomes a candidate, bumps the term, and asks the others for votes. Win a majority and you're leader, sending heartbeats that reset everyone's timers. Kill the leader and watch a new election fire. Leader election and split-vote handling, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Quorum Dial</title>
      <link>https://vibeengines.com/lab/quorum-simulator</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/quorum-simulator</guid>
      <category>Lab</category>
      <description>Don't read about quorums — dial them. With N replicas, a write goes to W of them and a read consults R of them. When R+W&gt;N the read and write sets are forced to overlap, so a read always sees the latest write — strong consistency. Drop below that and reads can miss the newest value. Slide R and W and watch a read go fresh or stale. Tunable consistency, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Vector Clocks: Who Caused What</title>
      <link>https://vibeengines.com/lab/vector-clocks</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/vector-clocks</guid>
      <category>Lab</category>
      <description>Don't read about vector clocks — trace them. Three processes with no shared clock each keep a vector counting events they know about. A local event bumps your own entry; sending attaches your vector; receiving merges by taking the element-wise max. Compare two vectors and you can tell whether one event caused the other — or whether they're truly concurrent. Watch causality emerge on a timeline, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>CRDT Merge: No Conflict</title>
      <link>https://vibeengines.com/lab/crdt-merge</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/crdt-merge</guid>
      <category>Lab</category>
      <description>Don't read about CRDTs — merge them. Three replicas edit the same counter at the same time with no coordination, then sync in any order — and always converge to the exact same value. The secret is a merge that is commutative, associative, and idempotent (here, element-wise max of per-replica counts). Increment replicas independently, merge them, and watch every replica agree, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Rumor Mill: Gossip</title>
      <link>https://vibeengines.com/lab/gossip-sim</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/gossip-sim</guid>
      <category>Lab</category>
      <description>Don't read about gossip protocols — start a rumor. One node learns an update; each round, every node that knows it tells a random peer. The knowledge spreads like an epidemic — doubling each round — so all N nodes hear it in about log N rounds, with no central coordinator and graceful tolerance of failures. Watch a single update sweep a whole cluster, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Load Balancer</title>
      <link>https://vibeengines.com/lab/load-balancer-sim</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/load-balancer-sim</guid>
      <category>Lab</category>
      <description>Don't read about load balancing — distribute the traffic. A load balancer spreads requests across a pool of servers, but the strategy decides everything: round-robin cycles blindly, least-connections sends work to the least-busy server, and hashing pins each client to one server for stickiness. When requests have uneven cost, the naive strategies pile up on one box while least-connections stays smooth. Send traffic and watch the queues, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The TCP Sawtooth</title>
      <link>https://vibeengines.com/lab/tcp-congestion</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/tcp-congestion</guid>
      <category>Lab</category>
      <description>Don't read about TCP congestion control — watch the sawtooth form. A sender probes the network's capacity by growing its congestion window exponentially at first (slow start), then linearly (congestion avoidance). When a packet is lost, it halves the window and probes again. This additive-increase / multiplicative-decrease loop makes millions of independent senders converge to a fair, stable share. Grow the window, inject loss, and watch it recover — made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The DNS Journey</title>
      <link>https://vibeengines.com/lab/dns-journey</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/dns-journey</guid>
      <category>Lab</category>
      <description>Don't read about DNS — watch a name resolve. Typing a domain kicks off a recursive walk down a global tree: your resolver asks a root server (which points to the TLD), the TLD server (which points to the authoritative server), and finally the authoritative server (which returns the IP). Then it caches the answer so the next lookup is instant. Resolve a name step by step and watch the cache short-circuit a repeat lookup, made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The TLS Handshake</title>
      <link>https://vibeengines.com/lab/tls-handshake</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/tls-handshake</guid>
      <category>Lab</category>
      <description>Don't read about TLS — watch two strangers agree on a secret while everyone is listening. A certificate proves the server's identity, and an ephemeral Diffie-Hellman exchange lets client and server derive the same secret key from public numbers without ever sending it across the wire. Step through the messages, watch each side compute the identical secret, and see why an eavesdropper still can't read it — with real tiny-number DH math, a quiz, and theory.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Git Object Graph</title>
      <link>https://vibeengines.com/lab/git-object-graph</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/git-object-graph</guid>
      <category>Lab</category>
      <description>Don't read about how Git stores your code — build the object graph. Every commit is a snapshot, not a diff: Git stores file contents as blobs, directories as trees, and each commit points to a tree plus its parent. Everything is addressed by the hash of its content, so identical content is stored exactly once and unchanged files are shared across commits for free. Edit files, commit, and watch new objects appear and unchanged ones get reused — made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>How a Regex Runs: The NFA</title>
      <link>https://vibeengines.com/lab/regex-nfa</link>
      <guid isPermaLink="true">https://vibeengines.com/lab/regex-nfa</guid>
      <category>Lab</category>
      <description>Don't read about regular expressions — run one, state by state. A regex compiles to a small state machine (an NFA), and matching a string means tracking the SET of states the machine could be in at once — following epsilon jumps and consuming one character at a time. Because it tracks a set instead of guessing and backtracking, it matches in linear time with no catastrophic blowups. Feed characters into the machine for a(b|c)*d and watch the active states light up — made playable, with theory and a quiz.</description>
      <pubDate>Wed, 22 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Monolith vs Microservices</title>
      <link>https://vibeengines.com/handbook/monolith-vs-microservices</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/monolith-vs-microservices</guid>
      <category>Handbook</category>
      <description>Microservices don’t remove complexity, they relocate it from the codebase into the network. Why the real trigger to split is organizational (Conway’s Law), not code size, and why &quot;monolith first&quot; is the pattern behind most successful splits.</description>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Raft vs Paxos</title>
      <link>https://vibeengines.com/handbook/raft-vs-paxos</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/raft-vs-paxos</guid>
      <category>Handbook</category>
      <description>Provably equivalent in power, radically different to implement: Raft bets on a strong leader to make consensus reasoning-friendly; Paxos’s more general, leaderless formulation is more flexible and notoriously hard to get right. Why etcd and Kubernetes chose Raft.</description>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>CP vs AP Databases</title>
      <link>https://vibeengines.com/handbook/cp-vs-ap-databases</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/cp-vs-ap-databases</guid>
      <category>Handbook</category>
      <description>CAP theorem’s forced choice, precisely stated: CP systems refuse some requests to guarantee consistency during a partition; AP systems keep serving, possibly stale, data. Why this trade-off only bites during an actual partition, and how real systems pick per data type.</description>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Consistent Hashing: The Ring</title>
      <link>https://vibeengines.com/algorithm/consistent-hashing</link>
      <guid isPermaLink="true">https://vibeengines.com/algorithm/consistent-hashing</guid>
      <category>Algorithm</category>
      <description>Don't memorize consistent hashing — play the ring. Place servers and keys on a hash ring where each key belongs to the next server clockwise, add a node and watch only ~1/N of the keys move instead of nearly all (as hash % N would), then flip on virtual nodes to smooth a lopsided load. The sharding primitive behind caches, databases, and load balancers — made playable, with theory and a quiz.</description>
      <pubDate>Tue, 21 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Cryptography for Engineers</title>
      <link>https://vibeengines.com/handbook/cryptography-for-engineers</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/cryptography-for-engineers</guid>
      <category>Handbook</category>
      <description>Encryption from XOR up. The one-time pad — XOR each byte with a random, message-length, single-use key — is the only provably unbreakable cipher, and its three rules teach the whole subject. XOR is its own inverse (a⊕k⊕k=a), so decrypt is the same op; a zero key is the identity (why keys must be random); and the fatal mistake: reuse the key on two messages and c₁⊕c₂=p₁⊕p₂ — the key cancels and secrecy dies (the VENONA blunder). Scales to symmetric (AES) + public-key + nonces + TLS, and the engineer's rules: never roll your own, never reuse a nonce, secure randomness, hash passwords slowly. With worked math and runnable code.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The OAuth &amp; Auth Deep Dive</title>
      <link>https://vibeengines.com/handbook/oauth-auth-deep</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/oauth-auth-deep</guid>
      <category>Handbook</category>
      <description>How &quot;Sign in with Google&quot; lets an app act for you without ever seeing your password. OAuth swaps your credentials for a scoped, revocable token, delivered via a short-lived authorization code that's worthless on its own — turning it into a token needs a back-channel exchange the browser can't make. Two parameters guard the flow: state (a random value echoed back, blocking forged/CSRF responses) and PKCE (challenge = SHA-256(verifier), so a stolen code can't be redeemed without the secret). Plus authentication vs authorization, OIDC/ID tokens, and the traps (implicit flow, unvalidated tokens, wide scopes, token leaks). With worked math and runnable code.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Operating Systems Fundamentals Handbook</title>
      <link>https://vibeengines.com/handbook/os-fundamentals</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/os-fundamentals</guid>
      <category>Handbook</category>
      <description>How your machine runs hundreds of programs on a few cores and a fixed slab of RAM — by sharing what isn't enough. Two tricks carry the weight: round-robin scheduling slices CPU time into quanta so no process starves (paying for fairness in context-switch overhead), and virtual memory pages hot data into physical frames, faulting to disk on a miss and evicting the least-recently-used page (LRU) — so more frames means fewer faults. Plus the vocabulary (process/thread/context switch/system call/page fault/kernel vs user mode) and the traps (thrashing, over-threading, the million-to-one memory hierarchy). With worked math and a runnable scheduler + pager simulation.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Linux Internals Handbook</title>
      <link>https://vibeengines.com/handbook/linux-internals</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/linux-internals</guid>
      <category>Handbook</category>
      <description>Linux runs the world on one idea: everything is a file. A document, the keyboard, a socket, another program's output — all reached through a small integer (a file descriptor) with the same four calls: open, read, write, close. The descriptor table allocates the lowest free integer (0/1/2 = stdin/stdout/stderr), which is exactly how the shell redirects output; a pipe is a kernel FIFO whose two ends wire a | b so one tool's output becomes another's input; and fork/exec split process creation from program loading, opening the window where descriptors get wired. Plus the traps (fd leaks → EMFILE, pipe backpressure/deadlock, zombie processes). With worked math and a runnable fd-table + pipe.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Compilers Basics Handbook</title>
      <link>https://vibeengines.com/handbook/compilers-basics</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/compilers-basics</guid>
      <category>Handbook</category>
      <description>How a flat string like &quot;2 + 3 * 4&quot; becomes the meaning 14 (not 20). A compiler works in stages: tokenize the text into atoms, parse the tokens by precedence, then evaluate. Built around a tiny arithmetic pipeline — tokenize → shunting-yard → RPN eval — where the single precedence comparison is exactly where &quot;*&quot; is encoded to bind tighter than &quot;+&quot;, and parentheses override it. Then scale the same skeleton to real languages (AST, semantic analysis, optimization, IR/codegen, LLVM) and dodge the traps (parsing nested grammars with regexes, conflating stages, ignoring error positions). With worked math and a runnable end-to-end calculator.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Rust Handbook</title>
      <link>https://vibeengines.com/handbook/rust</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/rust</guid>
      <category>Handbook</category>
      <description>Rust refuses the old memory trade-off (safe-but-slow GC vs fast-but-dangerous manual free) with one idea: ownership. Every value has exactly one owner, freed when the owner's scope ends — no garbage collector, no manual free, never freed twice. Assigning or passing a value moves it (invalidating the original, so no double-free/use-after-move); to share you borrow under one rule — any number of shared references XOR exactly one mutable — which makes data races impossible; and clone() deep-copies when you truly need two. All checked at compile time, so safety costs nothing at runtime. Plus the guarantees table and the traps (cloning to silence the checker, fighting instead of listening, reaching for unsafe/Rc/RefCell too early). With worked rules and a runnable borrow-checker model.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Go Handbook</title>
      <link>https://vibeengines.com/handbook/go</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/go</guid>
      <category>Handbook</category>
      <description>Go makes concurrency approachable with one motto: don't communicate by sharing memory; share memory by communicating. Instead of threads poking at locked shared state, cheap goroutines (start with &quot;go f()&quot;, run hundreds of thousands, multiplexed onto a few OS threads) pass data through channels — typed pipes that carry the synchronization. The whole model hinges on one rule: when does an operation block? An unbuffered channel (cap 0) blocks a send until a receiver is ready (a rendezvous); a buffered channel (cap N) blocks only when full/empty; and a blocked op with no partner is a deadlock (which Go's runtime detects and panics on). Plus goroutine leaks and when a mutex is still the right tool. With worked rules and a runnable channel model.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Collaborative Editor</title>
      <link>https://vibeengines.com/systemdesign/collaborative-editor-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/collaborative-editor-system-design</guid>
      <category>System Design</category>
      <description>Build a real-time collaborative document editor like Google Docs, Notion or Figma. See why a whole-document lock kills concurrency, how naive position-based edits corrupt a document, how Operational Transformation's central sequencer works and where it bottlenecks, how CRDTs remove that bottleneck with causal, order-independent merges, why presence/cursors live outside the document's durable history, and how offline-first editing and tombstone garbage collection round out the design.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Calendar System</title>
      <link>https://vibeengines.com/systemdesign/calendar-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/calendar-system-design</guid>
      <category>System Design</category>
      <description>Build a shared calendar like Google Calendar or Outlook. See why storing every recurring occurrence explodes storage, how RRULE-based recurrence is expanded at read time with exceptions layered on top, how free/busy conflict detection stays fast via interval overlap, the timezone/DST trap that can silently shift a recurring meeting by an hour, how invite/RSVP fan-out avoids blocking the organizer, how reminders scale via a time-bucketed trigger index, and how devices sync incrementally.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Hotel Booking System</title>
      <link>https://vibeengines.com/systemdesign/hotel-booking-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/hotel-booking-system-design</guid>
      <category>System Design</category>
      <description>Build a hotel/room booking platform like Booking.com or Marriott. See why read-then-decrement inventory oversells rooms, how a multi-night stay needs an all-or-nothing atomic transaction across every date, how reserve-then-confirm with a hold TTL prevents both overselling and cart-abandonment loss, why dynamic pricing is cached rather than computed live, how search is split from the strongly-consistent booking path (CQRS), and how controlled overbooking is a business policy the same atomic system enforces.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Dating App</title>
      <link>https://vibeengines.com/systemdesign/dating-app-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/dating-app-system-design</guid>
      <category>System Design</category>
      <description>Build a swipe-based dating app like Tinder or Hinge. See why a live full-table nearby scan doesn't scale, how a geospatial index plus a swiped-exclusion set fixes candidate generation, the mutual-match race condition and how a database uniqueness constraint guarantees exactly one match, how ranked feeds are precomputed rather than live, why blocking is deliberately the strictest-consistency path in the whole system, and how bot/fake-profile detection runs quietly, asynchronously, off the hot path.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Ride-Matching Engine</title>
      <link>https://vibeengines.com/systemdesign/ride-matching-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/ride-matching-system-design</guid>
      <category>System Design</category>
      <description>Build the matching and dispatch engine at the heart of a ride-hailing platform — the specific subsystem deciding which driver gets which rider, not the trip lifecycle or payments. See why straight-line distance is a bad proxy for real ETA, why greedy one-at-a-time matching is globally suboptimal, how batch matching solves an assignment-optimization problem across a short window, surge pricing as supply/demand balancing, ingesting driver locations at write-heavy scale, and fairness for idle drivers.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design a Logging Pipeline</title>
      <link>https://vibeengines.com/systemdesign/logging-pipeline-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/logging-pipeline-system-design</guid>
      <category>System Design</category>
      <description>Build the ingestion pipeline that collects, buffers and delivers logs from thousands of services — the write path, not the query/search side. See why synchronous writes to a central log server are dangerous, local agent buffering, bounded backpressure and overflow policy, batching for throughput, where structured parsing should happen, at-least-once delivery with dedup, sampling at high volume, and why a logging storm can take down the very system it was meant to observe.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design an Email System</title>
      <link>https://vibeengines.com/systemdesign/email-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/email-system-design</guid>
      <category>System Design</category>
      <description>Build an email system like Gmail or Outlook. See why raw inbound mail can't land straight in a mailbox, retry-with-backoff for unreliable delivery across the open internet, layered spam/authentication filtering, per-user mailbox sharding, thread reconstruction via message headers instead of subject lines, delivery dedup and bounce-loop prevention, and IMAP-style incremental multi-device sync.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>Design an Online Judge</title>
      <link>https://vibeengines.com/systemdesign/online-judge-system-design</link>
      <guid isPermaLink="true">https://vibeengines.com/systemdesign/online-judge-system-design</guid>
      <category>System Design</category>
      <description>Build a code-execution judge like LeetCode, Codeforces or HackerRank's backend. See why running submitted code inline is a security catastrophe, what real sandboxing has to guarantee beyond just a container, async queue-based execution for contest-scale bursts, verdict determination across hidden test cases, CPU-time (not wall-clock) resource limits for fairness, judge determinism, and fair queueing so one flood of submissions can't starve everyone else.</description>
      <pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Git Internals Handbook</title>
      <link>https://vibeengines.com/handbook/git-internals</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/git-internals</guid>
      <category>Handbook</category>
      <description>Learn the model and the commands become obvious. Git as a content-addressed database: blobs, trees and commits; branches as 41-byte files; the three trees behind add/commit/reset; what merge and rebase mechanically do (and why rewriting shared history is a law, not a preference); the reflog recovery recipe; packfiles.</description>
      <pubDate>Sat, 18 Jul 2026 00:00:00 GMT</pubDate>
    </item>
    <item>
      <title>The Docker Handbook</title>
      <link>https://vibeengines.com/handbook/docker</link>
      <guid isPermaLink="true">https://vibeengines.com/handbook/docker</guid>
      <category>Handbook</category>
      <description>A container is a lie told by the kernel — namespaces (what a process sees) plus cgroups (what it uses), not a VM. Image layers and the cache-ordering rule that halves build times, multi-stage Dockerfiles that ship small, volumes vs bind mounts, name-based networking, Compose, and the handoff to Kubernetes.</description>
      <pubDate>Sat, 18 Jul 2026 00:00:00 GMT</pubDate>
    </item>
  </channel>
</rss>
