Skip to content

PATTERN Cited by 1 source

Replicated log application layer

Pattern

Layer applications (key-value store, distributed leases, locks) on top of a replicated log rather than embedding application semantics into the consensus protocol itself. The consensus service decides the log; applications interpret it.

Structure

┌─────────────────┐  ┌─────────────────┐
│  KV Store App   │  │  Leasing App    │
└────────┬────────┘  └────────┬────────┘
         │ read log events    │
    ┌────▼────────────────────▼────┐
    │      Replicated Log          │
    │  [slot 1] [slot 2] [slot 3]  │
    └──────────────┬───────────────┘
                   │ decided by
    ┌──────────────▼───────────────┐
    │     Consensus Algorithm      │
    └──────────────────────────────┘

Benefits

  • Separation of concerns — consensus handles agreement; applications handle semantics
  • Multiple applications per cluster — a single Meerkat replica hosts many applications, all reading from the same log
  • Generic events — the consensus layer doesn't care what's in the log events; only applications interpret them
  • Simplifies formal verification — verify the consensus layer once; applications are deterministic state-machine projections

Meerkat instance

In Meerkat, replicas translate client requests (e.g., KV get/put) into log events, distribute them via QuePaxa, and construct application state by applying decided events in sequence. Multiple application types (KV store, leasing) run on the same cluster.

Seen in

Last updated · 573 distilled / 1,747 read