Sovereign Cell Architecture: Regulation-Oriented System Design

Looking at this issue as a technical problem would be drawing the wrong framework from the very beginning.

Let me start with a short story.

A SaaS company operating in Europe has been growing for years by saying it is “multi-region”. Everything seems fine: the system works, customers come, the product grows.

Until one day the audit came.

Is the customer’s data in Germany really in Germany?

The team says “yes”; because there is actually a deployment in Germany.

But when we dig a little deeper, the picture changes. Backups are in the USA, logs are in a central system, and support teams can access data from different countries.

Technically the system still works. But in terms of regulation, the answer is clear: not compatible.

And from this point on, everything changes.

Most companies are redesigning the system not to scale, but because they are stuck with regulation.

So it’s not about performance; where the data resides, who has access to it, and whether this structure can survive when it comes under control.

The answers to these questions are hidden directly within the architecture. And that’s why this subject is not talked about very openly. Because if you set it up correctly, you will gain an advantage; if you set it up wrong, you will create errors that are difficult to detect but very expensive.

Actually, what we are doing here is not dividing the system, but the data.

At this point, the first mistake most people make is trying to divide the system.

However, the real problem is not the system, but the data.

Consider two customers using the same product. One is in Germany and the other is in Turkey. They both feel like they are using the same product; Same login, same interface, same experience.

But in the background, they are actually in two different worlds: one in the system in Germany, the other in the system in Turkey.

The sovereign cell approach means establishing exactly this distinction consciously.

Each cell is a system that works on its own: it has its own database, its own services, its own log and backup structure, and its own key management.

The global layer only directs. It knows where the user belongs and sends the request to the right place; It does not touch the data.

“Multi-region” and “sovereign” are the two most confused concepts. Multi-region is generally done for performance and availability. Sovereign structure is for control.

The hard question is: where does the data really reside?

At this point the issue becomes clear.

How many regions the system operates in is secondary; What really matters is where the data lives.

In most systems, the real picture is this: data starts in one place but spreads to other places. The database may be in one country; The backup may be in another country, the logs may be in a central system, the cache may be in a different place. Moreover, human access such as support, admin and operations teams are also added to this table.

So the data is dispersed not only technically but also organizationally.

The question posed by regulation is simple:

Does the data really stay within its boundaries?

And most systems cannot answer this question clearly.

The critical truth here is this: isolation is not a single level, it is a spectrum. Shared buildings are cheap but risky. Regional divisions are safer. Cell-based insulation is the most powerful model, but its cost is high.

The biggest mistake is to think that “the most isolated structure is the most correct”. The correct approach is to install as much insulation as you need.

Why are the approaches we have used so far not enough to solve this problem?

Classical approaches do not fully solve this problem.

Getting started with Monolith is easy. But on a global scale, monolith means moving the entire system to each country: same code, same dependencies, same operation. Result: the cost multiplies.

Microservice architecture brings flexibility. However, if the boundaries between services are not drawn correctly, data will travel between these services. From the outside, everything looks fine, but the data is not under control.

The multi-region approach is often a half-solution. You deploy the system to different regions, but data continues to circulate and access remains global. The problem is not solved, it is just postponed.

Many teams stop here; because the system appears to “work”. However, the real test is always done at the time of the audit.

There is actually only one thing at the heart of this whole issue: boundary design.

The issue eventually comes down to one thing:> How do you draw boundaries?

The Sovereign cell approach is to limit the data, not the system.

This is critical not only for compliance but also for risk management. When something goes wrong it shouldn’t affect the entire system; It should only affect the relevant part.

So what you’re actually doing is reducing the blast radius.

This is usually the place where we have the most difficulty when establishing the architecture.

In theory, everything is clear; becomes difficult in practice.

There are two layers.

The global layer directs and decides; It sends the user to the correct cell but does not retain any data. There is a single login and single platform experience for the user.

In the Cell layer, the real system operates: APIs, services, database, cache, storage, KMS, log and backup are here and local.

The real challenge is cost rather than technique.

The most expensive parts are generally logging, monitoring, tracing and backup. If you install these separately for each country, the cost will increase; If you collect it in the center, you violate the regulation.

The most difficult part of this architecture is not technical; establishing financial balance.

Another misconception is the “everything should be local” approach. Doing everything locally increases costs and makes the operation more difficult; Making everything central disrupts regulation.

The correct approach is:

Consciously decide what to keep local

How does a request actually move through the system?

When a request comes to the system, it is first met by the global layer. The user is identified, which country he/she belongs to is determined and the request is directed to the relevant cell.

From this point on, all processing takes place locally. Data is not moved to another country, keys are not used elsewhere, logs do not flow to another system.

If data is coming out, it is usually at the anonymous or aggregation level.

The rule is simple:

Raw data does not exceed the limit

So when would it be a better decision not to enter this architecture at all?

Not every problem requires this solution.

For small-scale, single-country or simple products, this approach creates unnecessary complexity. Operation, cost and complexity increase; No meaningful gain is gained in return.

The most common mistakes that teams make in real life are usually the following:

Teams that reach this point make similar mistakes: keeping data in the global layer, not limiting support access, sending backups to different countries or centralizing key management.

And despite this, most teams consider themselves compliant.

But when the audit comes, the truth comes out.

There is a simple way to tell if this architecture is set up correctly

Do a simple test.

Imagine a country completely shutting down its system.

Ask yourself this question:

Do other countries continue to operate?

If the answer is yes, you are on the right track.

Finally, the clearest conclusion from this subject is

It is not difficult to divide the services.

The real architecture is to draw the boundaries of the data correctly.

That’s what makes the real difference.