Offline-First Data Architecture for a National Postal Service | Necro Notes

Offline-First Data Architecture for a National Postal Service

Think about a postal branch as an autonomous data node. It can accept payments, register shipments, deliver parcels, and close operational shifts without a connection to the central platform. When connectivity returns, the branch uploads locally recorded operations and receives the central data it is authorized to use.

A national postal network may contain roughly 10k branches, ranging from small offices with one computer to large locations with dozens of workstations. It also includes mobile branches operating over weak cellular connections. Some locations experience severe packet loss, some remain disconnected for months, and some may never reconnect because the building, vehicle, or equipment has been destroyed.

These conditions rule out a conventional application that depends on a permanently available central database. Every branch requires local storage and operational autonomy. A dedicated synchronization and recovery layer connects the independent branches to the central platform.

The important idea in the diagram is that the system has two replication dimensions.

Horizontal replication keeps data available inside one physical location. Central database nodes replicate among themselves, and database nodes inside one branch can replicate over the branch network.

Vertical replication moves selected data between organizational levels. It connects the central platform with each branch, but it does not copy the complete national dataset into every location.

Architecture At A Glance

The main parts are the Central Platform, the Synchronization and Recovery Layer, and the independent Postal Branches.

The central platform contains the complete national view. Each branch stores enough shared reference data and branch-specific operational data to continue working independently.

The synchronization layer is responsible for:

detecting changes in central and branch databases

deciding which branch is allowed to receive a record

distributing shared reference data

transferring branch-created operations to the central platform

returning central corrections to the correct branch

storing delivery checkpoints

limiting concurrency and bandwidth

reconnecting unstable branches

switching to snapshot recovery when incremental history is no longer sufficient

This separation is important. The databases remain responsible for durable storage and local availability. The synchronization layer is responsible for organizational routing, data authority, throttling, and recovery.

Horizontal Replication Inside A Location

Horizontal replication happens inside one physical location.

The central platform runs a redundant database cluster so the loss of one database node does not stop the national system.

A branch is also treated as an isolated data location. A small branch may have one practical database node, while a larger office may use several local nodes. Workstations continue using the local database even when the connection to the central platform disappears.

The critical boundary is that horizontal replication never crosses from one branch into another. Each branch is an independent data island. Branches do not exchange operational records directly and one branch must never see another branch’s payments, shipments, or shifts.

Vertical Replication Between Organizational Levels

Vertical replication crosses the boundary between the central platform and a branch.

It is selective by design. There are two separate data paths because shared reference data and branch operational data have different owners.

Shared Reference Data

Reference data includes address directories, branch locations, working hours, service definitions, price lists, temporary closures, relocated offices, and replacement locations.

The central platform is authoritative for this information. The direction is strictly:

Central Platform → Synchronization Layer → Postal Branches

A branch can use this data while offline, but it does not publish local reference-data changes back to the central platform. A branch closure, relocation, or new working schedule must come from the authoritative central source.

Branch Operational Data

Operational data includes payments, subscriptions, accepted and delivered shipments, cargo operations, and shift opening or closing events.

This flow is bidirectional:

Branch → Synchronization Layer → Central Platform

and:

Central Platform → Synchronization Layer → Owning Branch

The first direction uploads work performed locally. The reverse direction delivers an authorized central correction or a centrally created record back to the branch that owns it.

Every operational document carries a branch ownership key. The synchronization layer uses that value as an isolation boundary. A record belonging to one branch must never be distributed to every other branch.

This is...