← Back to list

Why I Embedded a Raft Consensus Engine Inside a Go Binary to Build a Custom Orchestrator

Hemanth Kumar Mangalapurapu · 2026-06-09 15:13 · 0 claps · 2.6 min read
#golang #software-development #distributed-systems #design-systems
Open on Medium ↗
Wiki topics: PRD · Product Design

Why I Embedded a Raft Consensus Engine Inside a Go Binary to Build a Custom Orchestrator

If you have ever managed a Kubernetes cluster, you know that the compute nodes aren’t usually the problem. The real operational nightmare is managing the state.

In standard architectures, if a control plane node dies, the cluster needs to know exactly what was running and where. To solve this, Kubernetes relies on etcd—a highly available, distributed key-value store. But etcd requires its own cluster, its own quorum, and its own operational overhead. For small-to-medium deployments or edge computing environments, managing a dedicated distributed database just to run some containers is a massive, unnecessary tax.

I wanted to see if I could build a production-grade orchestrator that completely eliminated this external database dependency. The result was AuraDeploy, built entirely in Go.

Here is how I solved the distributed state problem by collapsing the database directly into the orchestrator’s binary.

The Problem: Achieving Consensus Without a Database

To build an orchestrator, you need a single source of truth. If an admin requests a deployment of three API replicas, the system must record that intent, assign those replicas to specific worker nodes, and guarantee that if the master node crashes, the replacement master knows exactly what the previous one was doing.

Without an external database to query, the control plane nodes must maintain this state themselves and perfectly synchronize it across the network. If they get out of sync (split-brain), you end up with orphaned containers or duplicate deployments taking down your network mesh.

The Solution: An Embedded Finite State Machine via Raft

Instead of building a stateless Go application that talks to a stateful database, I made the Go application stateful.

I integrated HashiCorp’s raft library directly into the core binary. Raft is a consensus algorithm that ensures a cluster of compute nodes agrees on the same series of state transitions.

Here is how the architecture handles state natively:

  1. The In-Memory Single Source of Truth: At the heart of AuraDeploy is a custom Finite State Machine (FSM). This isn’t a SQL table; it is an in-memory struct that holds the exact desired state of the entire cluster — every application, every node, and every network route.
  2. Log Replication Instead of Queries: When an engineer submits a YAML deployment via the GitOps pipeline, the API doesn’t run an INSERT statement. Instead, the Active Leader node appends a command to its local Raft log.
  3. Achieving Quorum: The Leader broadcasts this log entry to the Passive follower nodes. Only when a majority of the nodes acknowledge receipt does the Leader commit the log, applying the mutation to its internal FSM and instructing the followers to do the same.

By doing this, I achieved a true Active-Passive High Availability Control Plane. If the leader dies, the Raft protocol automatically holds an election. The new leader instantly takes over the scheduling loop because its internal memory is already a mathematically proven, exact clone of the previous leader’s state.

Escaping the Abstraction Layers: Native CRI Integration

Once the state was secure, the next problem was execution. How do the worker nodes actually spin up the containers based on this FSM?

Most DIY orchestrators take the easy route: they just programmatically execute docker run commands in the host's shell. But Docker is a heavy abstraction layer. To build a true system-level orchestrator, I had to bypass Docker entirely.

AuraDeploy acts as a native Container Runtime Interface (CRI) client, communicating directly with containerd/oci.

  • When a worker node claims a pod from the Raft log, it doesn’t call a CLI.
  • It programmatically pulls the OCI image, leverages underlying snapshotters for filesystem isolation, and manually splices veth pairs into the host bridge (aura0) using raw Linux netlink commands.

The Takeaway

We are taught that microservices and decoupled databases are the only way to build reliable distributed systems. But building AuraDeploy proved that monolithic architectures still have incredible power.

By embedding the Raft consensus directly into the Go binary and writing a custom CRI client, you can achieve the self-healing and real-time state synchronization of Kubernetes, but compiled down into a single, highly efficient executable.


메타데이터
post_id
fcfb217b5955
slug
why-i-embedded-a-raft-consensus-engine-inside-a-go-binary-to-build-a-custom-orchestrator-fcfb217b5955
url
https://medium.com/@hemu1808/why-i-embedded-a-raft-consensus-engine-inside-a-go-binary-to-build-a-custom-orchestrator-fcfb217b5955
canonical_url
https://medium.com/@hemu1808/why-i-embedded-a-raft-consensus-engine-inside-a-go-binary-to-build-a-custom-orchestrator-fcfb217b5955
author_url
https://medium.com/@hemu1808
status
ok
fetched_at
2026-06-10 08:17:25