DevOps for Retail — peak-ready multi-cloud

What regulates the infrastructure

What actually goes wrong here

• Store WAN or uplink loss stopping the tills: unlike a web outage this halts trading at a physical location, which is why POS software is expected to run in offline mode and reconcile later — and why the real defect usually surfaces at reconciliation, as duplicated or lost transactions.
• Divergence between store stock and the web-facing availability feed, which breaks click-and-collect and ship-from-store promises and generates cancellations at the point the customer has already paid.
• Pricing or promotion engine error propagating to the whole estate at once — an incorrect price or a promotion that stacks unintentionally is replicated to every till and every electronic shelf label before anyone notices.
• PIN pad tampering or skimmer installation at a single store, which is a compliance and fraud event with no availability signal at all and is only caught by the physical inspection regime PCI DSS 9.5.1.2 requires.
• Loyalty or CRM service outage blocking discount redemption at the till, converting a back-office dependency into visible queues.
• Refrigeration and cold-chain telemetry loss in grocery, where undetected temperature excursion means stock write-off and food-safety exposure rather than an IT incident.
• Central authentication or directory failure locking store staff out of the POS at opening time — an outage whose blast radius is every store simultaneously.

How demand behaves

Physical and omnichannel retail load is distributed across a store estate rather than concentrated in one origin, and it follows footfall: weekday evenings, weekends, month-end paydays, and long tails around public holidays. Grocery in particular has a Ramadan pattern that inverts the normal day — daytime trade falls and a heavy pre-iftar and late-night peak appears — and an Eid al-Adha fresh/livestock peak. Each store is an edge site whose availability depends on its own WAN link, so the failure unit is 'one store for two hours', not 'the whole platform'.

Data you will be holding

Cardholder data at the point of interaction, loyalty profiles linking identity to detailed purchase history, and CCTV footage of identifiable individuals. Biometric processing (facial recognition for loss prevention) is a special category under GDPR and is treated restrictively in most EU jurisdictions.

Architecture this pushes you toward

The estate is a set of edge sites with intermittent connectivity, so state is deliberately duplicated: local POS databases that sync upward, central pricing and promotion masters that push downward. The hard problems are conflict resolution during sync, consistent price and stock propagation to hundreds or thousands of endpoints, and keeping the cardholder-data environment segmented from everything else sharing the store LAN.

Availability expectation

No statutory requirement. The operative expectation is not a percentage but degradation behaviour: tills must keep taking payment when the network is down, so architectures are judged on offline tolerance and reconciliation correctness rather than on headline availability.