Skip to main content

Transit, Explained

Transit is an append-only event line built for systems that need more than a flat log.

It gives you:

  • streams for ordered immutable history
  • branches for cheap divergence without copying old records
  • merges for explicit reconciliation
  • tiered storage so local hot state and remote history stay separate and visible
  • one engine that can run embedded in-process or as a networked server

Transit is not a Kafka rebrand. It is built for workloads where the history of a stream is part of the product: AI traces, experiments, communication threads, and derived views. Anywhere you need to show how state arrived at its current value, not just what that value is now.

The Engine In Three Layers​

Transit keeps three layers visible instead of collapsing them into one vague "durable log":

  • a hot local head for low-latency append and replay
  • immutable lineage and manifest metadata that explain how history is structured
  • a remote tier that stores colder immutable history without changing the core model

That same engine can be linked directly into your process or exposed through a daemon. The delivery mode changes. The storage semantics should not.

The Rail Network Model​

Think about a rail network instead of a single straight track.

  • A stream is a line with ordered stops.
  • A branch is a spur that leaves the main line at a known junction.
  • A merge is an explicit interchange back into another route.
  • A manifest is the timetable and routing sheet for immutable segments.

That metaphor matters because Transit treats divergence as a normal operating mode, not as an error the application has to hide.

Two Ways To Use Transit​

Transit has one engine and two delivery modes:

  • Embedded / library mode when your process wants direct local access to append, replay, branch, merge, and publish history.
  • Server mode when you want the same semantics over a network boundary through the Transit daemon and client surfaces.

Those are packaging choices on top of the same storage semantics. The server is not a second database.

What Transit Tries To Keep Explicit​

Transit is opinionated about several boundaries that many systems blur:

  • history is immutable once acknowledged
  • durability claims are explicit
  • branches are real lineage, not hidden copies
  • remote object storage is part of the system design
  • derived state is downstream of replay, not a rewrite of source history

These rules are load-bearing. When a page simplifies for narrative reasons, it does so on top of them. Never around them.

What Transit Already Ships​

Today the project already includes:

  • a local shared engine with append, replay, branch, merge, and status inspection
  • a server surface with streams, produce, consume, lineage inspection, and tail sessions
  • tiered publication, cold restore, warm-cache recovery, and transit storage probe
  • manifest-root integrity checks, materialization checkpoints, and reference projections
  • controlled failover, automatic lease election, and quorum durability in the shared engine

The fastest public summary of those slices is Capabilities.

If you are brand new:

  1. Read Choose Your Track.
  2. Read Capabilities.
  3. Follow either the embedded/library first run or the server first run.
  4. Come back to the concept pages when you want the model behind the proofs.

What Comes Next​

Start with Choose Your Track if you want the fastest path into the repo.