Before you split the code, decide how to split the customers

Imagine delivering the same solution to seven customers: a bank and six mid-sized retail chains. The bank does not want its data sitting alongside anyone else’s and will accept updates only once a quarter. The retail chains want new features as soon as possible.

The first architectural question engineering teams tend to ask is monolith or microservices. For an FDE, the more important question is how to split the customers: who shares infrastructure, who gets a dedicated copy, and who receives updates when.

Microservices split code; deployment stamps split customers. Confuse the two and you end up with an expensive system that still fails to satisfy your most demanding customer.

Microservices solve a different problem

AWS presents microservices with a clear benefit: services are independent of one another, so the application tolerates failure better. The benefit is real, but it comes at a price. As early as 2014, Martin Fowler noted that distributed transactions are notoriously difficult to get right.

Fowler’s advice is also practical: start with a monolith, keep it modular, and split it into microservices only when that monolith starts causing problems. This suits FDE work, where you usually have few people, little time, and a system that must run in the customer’s environment before anyone discusses whether the architecture is elegant.

There is a frequently cited number pointing the other way. An internal Amazon case study, reported by DevClass in May 2023, described how the Prime Video team responsible for monitoring audio/video quality consolidated distributed components into a single process and cut infrastructure costs by more than 90%.

That result holds for that team’s situation only, but it is a reminder that breaking things apart is never free.

Back to the bank from the opening. Splitting the system into 12 services meets neither of its two requirements.

Even with 12 services, the bank still shares a database and a release schedule with every other customer.

Consolidating compute is cheap, but everything is coupled

The Azure Architecture Center has a pattern close to the monolith’s “consolidate to save money” spirit: Compute Resource Consolidation, which shares compute across multiple tasks to reduce cost. The pattern concerns how tasks run on infrastructure rather than how code is organised, but it shows plainly what consolidation costs.

According to that documentation, updating one task means stopping, redeploying and restarting every other task in the same compute unit; consolidated tasks also share a fault domain and a security context.

The same documentation states that tasks handling highly sensitive or private data should not be consolidated, because they need their own security context. Put that in the context of delivering to many customers and the limit of running everyone in one block becomes clear: it works until the first customer demands data isolation.

Even if you keep the monolith, there is one mistake worth avoiding from the start. Microsoft classifies putting all data into a single data store as an antipattern, because it causes resource contention and degrades performance. The recommendation is to separate data according to how it is used.

A monolith at the code level does not oblige you to use one database for everything.

Stamps: split by customer, not by function

Deployment stamps approach the problem from a different direction. Rather than splitting the application into parts, you deploy multiple independent copies of the whole application, each with its own data store. In a multitenant environment, each stamp serves a predefined set of tenants.

Microsoft describes a scenario very close to FDE work: some large customers may need dedicated instances, while smaller customers share a multitenant deployment. Stamps also address update cadence.

Some customers accept frequent updates; others are risk-averse and want them rarely, so each stamp can follow a different deployment ring.

Apply this to the seven customers from the opening: stamp A serves only the bank, with its own data and security context. Stamp B is shared by the six retail chains.

Each new release goes to stamp B first, runs cleanly for a few weeks, and only then reaches stamp A. The code remains a modular monolith; only the deployment changes.

Criterion	Compute Resource Consolidation	Microservices	Deployment stamps
Axis of division	No division; many tasks share one compute unit	Code split by function	Customers split into tenant groups
Release cadence	Changing one task means redeploying the whole unit	No per-customer cadence	Each customer group has its own ring and cadence
Isolation of sensitive data	Shared security context; unsuitable	Not solved per customer	Large customers can have a dedicated stamp
Main cost	Shared fault domain	Distributed transactions are hard	Much more infrastructure; hard to move tenants
Choose when	Tasks do not need separate security contexts	The monolith is genuinely causing problems	Customers differ on isolation or update cadence

The table is easy to read as three mutually exclusive options, but it is not. Stamps are a way to deploy, while monolith versus microservices is a way to organise code, so a modular monolith can run on many stamps, as in the bank and retail example above.

Every copy costs money

Microsoft is also clear about the price: deploying multiple copies of infrastructure significantly increases operating costs. Moving a tenant from one stamp to another is also hard. So the decision about which customer goes on which stamp should be made carefully during customer discovery, not left until the customer is already in production.

Running multiple stamps requires infrastructure as code and drift control. Without them, stamps diverge a little more every time someone makes a manual change in a customer’s environment. Microsoft also recommends deploying at least two stamps, because with only one it is easy to hard-code assumptions that hold only when there is a single instance.

Conversely, stamps are not the default choice. According to Microsoft, if the solution is simple, does not need to scale much, or a single instance can handle the load, the pattern should not be used. If you have only one customer, or every customer is happy to share, a modular monolith with sensibly separated data is enough.

When customers require data to stay in a specific region

There is one more option: the geode, where every instance can serve any user rather than a single customer group as with stamps. Microsoft says geodes are usually much more complex to design and build, and suit cloud-native platforms with no constraints on data location.

So before considering geodes, ask customers at the outset whether they have data location requirements. Microsoft states that geodes are unsuitable where there are data residency requirements, or where the application must hold temporary state for a session.

In those cases, Microsoft recommends stamps combined with a global routing layer that directs requests to the right stamp.

If your customer requires that data never leave a given region, as banks, hospitals or government agencies often do, the answer is almost ready-made: one stamp per region, with a routing layer in front. It is not the most theoretically elegant option, but it is one you can explain to the customer’s compliance team.

For developers aiming for FDE roles

When reading a job description for an FDE or solutions engineer role, look for phrases such as multi-tenant, single-tenant deployment, dedicated instance and infrastructure as code. They signal that the company is dealing with exactly this customer-splitting problem and needs people who understand both architectural axes.

On your CV, do not just write “migrated the system to microservices”. Spell out how you decided to deploy and why: which customers got dedicated instances and for what reason, how release cadence was divided, and what you did to keep environments from drifting.

A story about a decision with weighed trade-offs is far more persuasive than a list of technologies.

In an interview, if asked “monolith or microservices?”, a good answer usually begins with a question back: how many customers are there, and how do they differ? In an FDE role, how you split your customers often decides the fate of the project more than how you split your code.