Reliability and delivery
Pigeon chooses reliability over speed. Messages may wait out an outage; once a message has been accepted, it is never dropped.
The rule
A message counts as sent when three of its mailbox's five replicas have written it to disk and acknowledged it. From then on it is never dropped: delivery completes once enough replicas are reachable again. The receiving device acknowledges a message only after storing it, so a crash on the receiving side doesn't lose it either.
The delivery target
| Condition | Target |
|---|---|
| Every case | At least 99.9% of accepted messages delivered; the design goal is no loss at all |
| Normal: three or more of five replicas reachable | Latency measured and published: p50 0.74 s, p95 1.77 s, p99 4.76 s in the latest clean soak |
| Outage: fewer than three reachable | No latency target; reported as time until quorum returns |
The normal-case latencies are an upper bound: the harness doesn't yet separate out messages sent while a quorum was lost.
Measurements
These come from soak tests: five nodes and 20 clients on a test swarm, under a seeded schedule of kill -9s, wiped nodes, network partitions and dropped requests. They are not from a production network; there is no production swarm yet.
| Run | Length | Messages lost | p99 latency |
|---|---|---|---|
| Soak, seed 3 | 60 min | 0 of 33,361 | 8.75 s |
| Soak, seed 4 | 60 min | 0 of 33,540 | 7.10 s |
| Soak, seed 4 (clean) | 45 min | 0 of 25,629 | 4.76 s |
Latency is end to end, from creation to the recipient opening the message, measured outside each run's final window. Earlier runs found and fixed two loss bugs: a receive path that acknowledged before storing (7 of 20,448 lost), and a hedged-quorum change that was rejected because it lost 2 of 8,850. The remaining tail latency is quorum loss under three-node partitions, which a three-of-five write produces by design.
Why it holds
- Nodes commit every write durably before acknowledging (architecture).
- Clients read from all five replicas and repair gaps.
- Group changes are agreed through a model-checked commit protocol (ordering).
Known gap: delivery receipts are Planned; production monitoring and alerting don't exist yet.
Sources: docs/OBSERVABILITY.md (delivery SLO v2), ADR-0002 (replication), ADR-0004 (persistence), the soak records in changelog.d/.