Multi-branch retail operations push schema design, sync, and offline tolerance to their limits. We share how we modeled branch isolation, central catalog, and the operational discipline that kept release velocity high.
The schema decision that changes everything
The first decision in a multi-branch ERP is whether ‘branch’ is a top-level entity or a column. Get this wrong and every report, permission boundary and migration becomes harder forever.
We model branches as first-class tenants of a tenant — every transaction, stock movement and price override is bound to a branch. The central catalog and bullion linkage live above the branch layer. This keeps reporting clean, keeps permissions sane, and lets a branch operate degraded if connectivity fails.
Sync, but only where it matters
Branches don’t need full bidirectional sync. They need to never lose a transaction and to always know prices. We use an append-only outbox at the branch and a backfill protocol at the centre. Read models are eventually consistent. Pricing is hot-pulled.
- Outbox-pattern writes at the branch.
- CDC streams from branch to centre.
- Hot-pull pricing & bullion at billing time.
- Daily reconciliation jobs with variance dashboards.
Velocity, even on a multi-branch product
Multi-branch products earn a reputation for being slow to ship. We don’t accept that. Feature flags per branch, opt-in rollouts, and a small set of synthetic branches in production keep us shipping daily without breaking real operations.
Every feature rolls out to one branch first, with a hard rollback gate. Then five. Then everyone. Velocity comes from blast-radius control, not from cowboying.
What we’d still change
If we started from scratch today, the only meaningful change would be more aggressive embedding of AI evaluation into the reconciliation loop — surfacing anomalies the moment they happen, not at end-of-day.
