What Cross-Market Data Engineering Actually Looks Like

Building across +5 markets taught me one thing faster than anything else: data governance is not a compliance checkbox you add at the end. It is a structural decision you make in week one, or you pay for it in week forty. I have built fintech systems, public sector tools, and SaaS platforms across Cameroon, Switzerland, Germany, the UK, and the US. Each market has its own rules about where data can sit, who can read it, and what happens when a user asks for deletion. Getting that wrong is not a legal inconvenience. It breaks the product.

The constraint that shapes everything before a line of code

When a client comes to me comparing partners, the first thing I want to understand is not their feature list. It is where their users are and where their data is allowed to go. That question used to be manageable with a centralized data lake and a good privacy policy. It is not manageable that way anymore.

The EU Data Act became fully applicable in late 2025. India's DPDP Act enforcement followed. The result is that federated data architectures, where each jurisdiction holds its own data and shares only what is necessary, have become the default for any serious multi-market build. Distributed SQL databases with native geo-partitioning are the standard tool. A centralized global store is now a liability, not a simplification.

I learned this the hard way on an earlier build, before the current enforcement wave. We shipped a centralized architecture, then spent three months retrofitting geographic partitioning after a compliance review flagged cross-border data transfers. The retrofit cost more in engineering time than the original build. I do not do that anymore.

How the first two weeks of an engagement actually run

The first call is not a pitch. I ask the client to walk me through their user journey end to end, and I listen for where personal data appears. It appears in more places than most founders expect. Authentication tokens, payment metadata, usage logs, support transcripts. Each one is a data category with its own regulatory treatment depending on jurisdiction.

By the end of week one I want a data flow map. Not a system architecture diagram. A map that shows what data is collected, where it is stored, who can access it, and what the deletion path looks like. That map becomes the reference document for every technical decision that follows.

Week two is where I push back on assumptions. Founders often arrive with a mental model of a single global database because that is what they have seen in tutorials. I explain why that model fails at the point where a Swiss user's data cannot legally sit on a US server without specific safeguards. We agree on the architecture before we write a schema.

What federated architecture means in practice

Federated does not mean complicated. It means deliberate. Each regional deployment holds the data for its users. A coordination layer handles cross-region queries where they are legally permitted. The application layer abstracts the routing so that product engineers do not have to think about jurisdiction on every query.

On the Financial Services Platform I built for a fintech client, response times dropped thirty percent after we moved from a single-region architecture to a geo-distributed one. That was partly latency, because users were hitting nodes closer to them, and partly because we eliminated a class of expensive cross-region joins that had been slowing down the most common queries. The compliance improvement and the performance improvement came from the same structural decision.

For OptimalTax, a public sector tax automation tool, the data residency requirement was non-negotiable from the start. Tax data has to stay in jurisdiction. We built the storage layer around that constraint first, then designed the calculation engine on top of it. The result was ninety-nine percent tax calculation accuracy and a system that passed its audit without a single finding related to data handling.

The parts that do not show up in architecture diagrams

Data governance is not only about where data sits. It is about what happens when something goes wrong. A deletion request arrives. A breach notification deadline is forty-eight hours away. A regulator asks for an audit log.

I build deletion pipelines before I build feature pipelines. That sounds backwards, but it is the right order. If you cannot delete a user's data cleanly, your architecture has a hidden coupling somewhere. Finding it during a deletion request is the worst possible time.

Audit logs are another area where I have seen teams cut corners. Logs need to be tamper-evident, timestamped to the right granularity, and retained for the right duration per jurisdiction. Those durations differ. Germany and Switzerland have different retention requirements for financial logs than Cameroon does. The logging layer has to know which rules apply to which records.

I also build data inventories as living documents, not one-time audits. Every time a new data field is added to the schema, the inventory gets updated. That discipline feels slow in a sprint. It saves weeks when a compliance review arrives.

What I hand over at the end

At the end of an engagement, the client gets working software. They also get the data flow map, updated to reflect the final architecture. They get the deletion runbook. They get the audit log specification. They get documentation of every jurisdiction-specific decision and the reasoning behind it.

I do this because I have seen what happens when a technical founder tries to hand a system to a new engineering team with no documentation of the compliance decisions. The new team does not know which constraints are legal requirements and which are just conventions. They change the wrong thing. The audit finds it.

The Workbud Workshift Platform is a good example of a handover done right. Shift management touches employment data, which has its own regulatory treatment. We documented every data category, every retention period, and every access control decision. The client's internal team took it over without a gap.

Starting a conversation is the right first step

If you are comparing partners for a multi-market build, the question to ask each one is not what stack they use. Ask them where your data will live on day one and what the deletion path looks like. The answer tells you whether they have done this before.

I have built across Cameroon, Switzerland, Germany, the UK, and the US. The work section shows the range. If the constraints you are facing sound like the ones I have described here, let's talk.