Elie Hannouch on foojay.io - Friends of OpenJDK

MongoDB and the Raft Algorithm

Tue, 24 Feb 2026 15:47:27 +0000

MongoDB’s replica set architecture uses distributed consensus to ensure consistency, availability, and fault tolerance across nodes. At the core of this architecture is the Raft consensus algorithm, which breaks the complexities of distributed consensus into manageable operations: leader election, log replication, and commitment. This document explores how MongoDB integrates and optimizes Raft for its high-performance replication needs.{#1c95}

Raft Roles and MongoDB’s Replica Set

In Raft, nodes can assume one of three roles: leader , follower , or candidate . MongoDB maps these roles to its architecture seamlessly. The primary node functions as the leader, handling all client write operations and coordinating replication. The secondaries serve as followers, maintaining copies of the primary’s data. A node transitions to the candidate role during an election, triggered by leader unavailability.{#5e79}

MongoDB and WiredTiger: A Journey Through the Storage Engine

Thu, 18 Dec 2025 20:26:28 +0000

Databases are the backbone of modern applications, and MongoDB stands out with its flexibility and scalability. Central to its functionality is the WiredTiger storage engine. WiredTiger, as MongoDB’s default engine, seamlessly merges document-level concurrency for high throughput, advanced compression techniques for optimized storage, and an in-memory architecture for rapid data access.{#e668}

With the addition of write-ahead logging for robust durability and the sophistication of MultiVersion Concurrency Control for snapshot-like data views, WiredTiger harmoniously orchestrates MongoDB’s data management.{#6fac}

Inside the Engine: Performance Relay of MongoDB 8.0

Tue, 16 Dec 2025 20:16:42 +0000

In environments where microseconds dictate competitive advantage, MongoDB 8.0 delivers a meticulously tuned execution pipeline that transforms raw network packets into sub-millisecond query responses at global scale.{#e2e4}

This reference traces a single trade query through every internal boundary network ingress, scheduling, security, parsing, planning, execution, storage‐engine internals, indexing, replication, sharding, change streams, time‐series buckets, backup, and monitoring illustrating how MongoDB 8.0’s per-CPU allocators, active-work profiling, SIMD-vectorized execution, adaptive bucketization, compact resume tokens, and refined journaling coalesce into a seamless, predictable performance engine.{#e2e4}

Building Systems That Know Why They Exist ~ When Data, Logic, and Intent Finally Align

Thu, 04 Dec 2025 19:06:35 +0000

Every software system begins with intent. A human decision. A statement of what should exist, how it should behave, and why it matters. But somewhere along the way, that intent dies. It’s decomposed into documentation, user stories, and scattered logic. It becomes a shadow of itself fragmented across layers of code, processes, and people who no longer remember what it was meant to achieve.{#7cd1}

We’ve automated infrastructure. We’ve scripted configurations. We’ve even made AI write code for us. But we’ve never automated understanding . Our systems execute brilliantly yet comprehend nothing. They operate without memory of purpose. They run, but they do not know why.{#657d}

How MongoDB Decides What to Forget?

Tue, 28 Oct 2025 14:00:39 +0000

Inside MongoDB’s storage engine, WiredTiger , nothing happens by accident.{#4cf7}

Every page in memory exists under policy — governed, measured, and continuously evaluated against the limits of RAM, I/O bandwidth, and checkpoint cadence. Eviction is not cleanup. It’s runtime arbitration between volatility and durability.{#ba51}

When the process starts, WiredTiger allocates a fixed memory region known as the cache arena typically 50% of physical RAM. Within that space live B-tree pages : internal nodes, leaf nodes, and history-store entries. Each page carries operational metadata: dirty, clean, hazard-protected, in-use, last_access_time, and generation . This metadata feeds into a per-page score, which informs the eviction subsystem’s next decision.{#61cb}