Multi-Country Retail Data Platform — Target Architecture

In a multi-country retail group the reporting arguments always land in the same place: the same word produces different numbers in two teams.

The first reflex is volume: the data has grown, so a distributed stack is needed. The diagnosis does not support that. Around 150 million rows a year is a size a single partitioned relational database carries comfortably.

The problem sits in three other places. Definition: "net sales" varies from team to team. Authority: nobody owns publishing a metric. Latency: inconsistency is only noticed once it has grown large enough.

Six documents and five decision records. Because the diagnosis is not volume, most of the architecture is a list of reasoned exclusions: distributed processing, a data lake and streaming infrastructure are not built, and the reason is written down for each.

What is built is a layered relational warehouse with a single semantic layer on top. Power BI, Excel and language-model access all connect to that layer: if a definition does not live in one place, it lives in three and produces three numbers.

The language model is not given free SQL. It gets tools shaped as metrics from a tool server, and those tools run with the permissions of whoever asked; no question lets the model see a row the user cannot.

The first constraint on the migration order is not technical but adoption: no old path is closed before the new one is seen working.

What was delivered is not a running system but a target architecture and a phased migration path: six documents, five decision records, each with the condition under which it would be reversed.

Here is the honest limit: the project is at the design stage. No migration phase was completed, and the volume figures are derived from the shape of the business rather than measured.

The value of the documents is not in prediction but in elimination: most of the architecture consists of components ruled out by showing they were not needed.