Problem
A QSR operator approached Offline Protocol because a connection failure could stop an otherwise functioning restaurant. Registers retained transactions, but the kitchen still needed the order, the runner needed its status, and head office needed the completed history. Staff bridged the gaps with verbal instructions, manual tickets, and re-entry, increasing queue time, remakes, and reconciliation work.
Solution
The deployment moved active order coordination onto restaurant devices using the Offline Protocol Mesh SDK1. Data Edge Sync2, Offline Protocol's replicated-data layer, synchronizes accepted orders, preparation progress, and collection status across the counter, drive-thru, kitchen, and handoff team. Automatic transport selection keeps those updates moving over available qualified paths. Retained events and duplicate-safe retries protect the order history through interruptions, and the store gateway reconciles it with enterprise systems after connectivity returns.
Outcome
Crews coordinate fulfillment faster because each station can see what has been accepted, what is being prepared, and what is ready for handoff without repeatedly checking with another team. The same shared workflow keeps eligible orders moving during WAN interruptions, avoiding a switch to verbal instructions and manual tickets while a local path remains available. The restaurant gains more efficient everyday service and resilience during outages, with completed order history returning to head office.
Deployment
The Offline Protocol Mesh SDK1 connects the point of sale (POS), drive-thru, kitchen display system (KDS), expo, and store gateway. Data Edge Sync2, Offline Protocol’s replicated-data layer, keeps their order documents synchronized. Dynamic Offline Relay Switch (DORS) automatically selects an available transport qualified for the deployed hardware. OfflineID3 supplies device identity, while encrypted group sessions protect order traffic.
The gateway retains the enterprise backlog. Hosted Relay forwards encrypted events to an authenticated recipient, whose adapter commits them to the existing order system. Relay provides transport; persistence and business ingestion remain with the endpoints.
Existing systems retain their roles. The POS owns pricing, tax, discounts, and tender rules; the KDS remains the preparation interface; the enterprise platform remains the central record. Card data and authorization requests stay outside order sync. Orders stranded at an unreachable marketplace need a separate ingress path.
Continuity needs a working local path. WAN loss can leave the store LAN intact. Access-point failure requires a qualified direct peer connection. With no usable local link, devices retain events and show pending kitchen acceptance rather than claiming delivery.
One order, end to end
The POS commits the order and outbox event atomically, then projects validated changes into Data Edge Sync through a durable queue. The kitchen checks the sender, permissions, schema, and event ID before committing its ticket and returning acceptance. Preparation and handoff update the same order; amendments require kitchen acknowledgment, and late cancellations become explicit exceptions. This gives each team control over its part of fulfillment while keeping the other stations informed. When connectivity returns, the gateway replays retained events until the enterprise adapter confirms its commit.
Correctness through interruption
Stored, accepted, and reconciled are separate facts. A transport acknowledgment4 is not a committed kitchen ticket. Every event retains its original order ID, event ID, device attribution, and revision across retries and restarts. The receiver records the event ID and business change together, so a lost acknowledgment triggers another response, not another meal.
Independent work needs independent fields. Each order document separates its header, line items with stable IDs, per-station status keys, and notes. The POS owns basket revisions, the kitchen owns preparation, and expo owns collection. Conflict-free replicated data types (CRDTs) converge the shared view; adapters still validate who may perform each business action. Same-field conflicts follow the defined merge rule, with invalid transitions handled as exceptions. The existing auth_ref is only a reference and cannot reauthorize payment.
Stack and implementation
| Product / component | Deployment role | Integration |
|---|---|---|
| Offline Protocol Mesh SDK + DORS | Local discovery, transport selection, encrypted delivery, and retries | @offline-protocol/mesh-sdk; offline-protocol-transport, offline-protocol-router, offline-protocol-reliability, and offline-protocol-services5. Platform bridges provide radio and socket I/O. |
| Data Edge Sync | Persist and synchronize per-order documents | offline-protocol-data, built on Loro CRDTs. DataStore provides maps, lists, text, and counters replicated across MLS spaces. |
| OfflineID + Messaging Layer Security (MLS) | Device enrollment and protected order traffic | Store-specific keys, roles, and authorization windows; offline-protocol-mls encrypts payloads. Discovery advertises minimal metadata only. |
| Relay + restaurant adapters | Enterprise delivery and business correctness | Endpoint outboxes, deduplication, projection queues, kitchen acceptance, and idempotent central ingestion. Relay forwards encrypted payloads. |
The deployed runtime uses offline-protocol and offline-protocol-core, with cross-language bindings through offline-protocol-uniffi. Restaurant adapters connect through vendor-supported POS/KDS extension points. Platform bridges provide radio access; browser-only applications reach that capability through a compatible native companion or connector.
Durable transaction boundaries. The sender commits each business change with its outbox entry. The receiver commits the event ID, order change, and acknowledgment state together, retaining deduplication history for the full replay horizon. A durable queue projects changes into DataStore; flush() makes them persistent before data_changed updates the application. Database and SDK writes remain separate, recoverable transactions.
Bounded replication. Small per-order documents live in restaurant-specific service-window spaces. Group members run compatible replication builds. Catch-up frames stay within the 32 KiB group-sync limit; data_doc_unsyncable raises an operational exception. Queue capacity covers the supported outage window, and rate-limited enterprise replay protects live orders. Windows reconcile before retirement; local deletion alone does not remove peer copies.
Hardware qualification. Device provisioning binds keys, state ownership, and offline eligibility to each restaurant. Hardware profiles define the supported local transports. Shadow comparisons and supervised channel validation gate rollout, including credential expiry and locally known revocation checks.
Validation
The engineering run uses four devices at 20 orders/minute, up to 10 events/order and 4 KiB/event, through a 30-minute WAN outage: 600 orders and up to 6,000 events. These are acceptance thresholds, recorded separately for each hardware and transport profile.
| Measure | Acceptance threshold | Verification |
|---|---|---|
| Kitchen acceptance | Every eligible order accepted; p95 within 2 seconds on the qualified primary local path | POS and kitchen commit receipts correlated with clock-error accounting. |
| Retention and duplicates | No lost committed events or duplicate kitchen tickets | Application restarts and threefold event replay, checked against event IDs and tickets. |
| Order correctness | No silent loss of amendments; invalid transitions surface as exceptions | Concurrent edits, reordered events, late cancellations, and clock skew. |
| Enterprise recovery | Clear 6,000 retained events within 5 minutes while live orders continue | Central commit receipts, ledger parity, queue age, and live-order latency. |
| Authorization | Wrong-store, expired, unknown, and locally known-revoked devices cannot apply updates | Rejection logs and unchanged business state. |
The failure suite covers lost acknowledgments, connector restarts, queue pressure, and intermittent WAN loss. Access-point failure is tested separately; a total local partition retains data and visibly withholds acceptance. Revocation learned later takes effect when received or when the offline authorization window expires.
The business scorecard compares matched service periods with normal, degraded, and unavailable connectivity: kitchen acceptance time, order-to-handoff time, completed orders per labor hour, manual interventions, remakes, abandonment, and reconciliation labor. Matched staffing, demand, and order mix isolate everyday efficiency and continuity gains from other changes.
Managed services and expansion
Telemetry6 exports permitted route, retry, queue, and application-acceptance events into a metered hosted stream. A non-blocking collector buffers observations; ingestion failure never holds up an order. Explicit payload schemas exclude customer and payment data.
Proof of Location7 extends the same store foundation to curbside pickup, custody checks, and service visits. The workflow captures presence evidence locally and verifies it under the selected freshness and witness policy when reachable; presence alone does not prove correct meal handoff.
Capability Exchange exposes approved diagnostics, availability lookups, or service requests through signed manifests and scoped invocation. Services can run locally or through an authorized hosted route, with request IDs, deadlines, and operation-specific permissions.
Together with Relay, these add hosted delivery, observability, verification, and invocation consumption. Metering, retention, and rates follow the production agreement; local peer traffic remains unmetered. Further workflows can reuse enrollment and synchronization for menu changes, ingredient-use events, staff handoffs, and equipment requests, each with its own business rules and validation.
