HomeMulti-Store POS
Multi-Store Architecture Guide

Multi-store retail automation architecture

Running more than one location introduces a new class of problems: how to keep master data consistent across stores, how to consolidate reporting, and how to ensure each location stays operational even when the central server is unreachable. A layered system can address this by separating local checkout, store coordination, and central tenancy. SaleFlex is one implementation of that pattern.

Evaluate SaleFlex Architecture

The core challenge of multi-store retail

A single-store POS can get away with storing everything locally. Once you add a second location, you need answers to harder questions:

Master data consistency

When product prices or campaign rules change at headquarters, how quickly and reliably do those changes reach every store terminal?

Per-store autonomy

If the central server or internet goes down, does each store stop working? Or does it continue operating on local data until connectivity returns?

Consolidated reporting

How do you get a single view of sales, inventory, and loyalty activity across all locations without manually merging reports?

Security boundaries

Store managers should see their own store's data. Regional managers see their region. Headquarters sees everything. How is that enforced?

SaleFlex's multi-store architecture: Company → Store → Terminal

SaleFlex addresses multi-store management through a three-level hierarchy that scopes every piece of data — and every API call — by company, store, and terminal.

 Company
Top-level tenant. Owns all stores, policies, and central campaigns.
 Store (Location)
Physical location. Has its own warehouse, terminals, and local reporting.
 POS Terminal
Individual register. Identified by POS number, registers with store via GATE.

SaleFlex.GATE enforces this hierarchy at the API level. JWT tokens and device API keys are scoped to company, store, and terminal boundaries. Data at each level is partitioned and cannot leak across boundaries.

How each layer handles multi-store scenarios

PyPOS — Store floor

Each PyPOS terminal operates independently on local SQLite. It identifies itself by POS number and store. Changes from GATE (products, campaigns) are pulled by the background sync worker.

OFFICE — Store level

OFFICE manages master data for its own store: products, campaigns, customers, warehouse. It serves as a local data hub for PyPOS terminals and syncs upstream to GATE when internet is available.

GATE — Central level

GATE aggregates data from all stores, enforces company-level policies, and exposes versioned REST APIs. Central campaign rules, pricing, and reporting live here — scoped strictly by company and store.

A practical path from one store to many

Start with standalone PyPOS, add OFFICE for store coordination, then introduce GATE for central APIs and multi-store management. Each layer has a distinct responsibility.

Get Started Full Architecture