Sponsor: Using RabbitMQ or Azure Service Bus in your .NET systems? Well, you could just use their SDKs and roll your own serialization, routing, outbox, retries, and telemetry. I mean, seriously, how hard could it be?
I want to give you three different examples and reasons why you might want to separate customers and orders into different databases. The person who asked the question left out a lot of nuance and context, so I am going straight to the point. You will find all three examples boil down to the same underlying reason.
YouTube
Check out my YouTube channel, where I post all kinds of content on Software Architecture & Design, including this video showing everything in this post.
1. Third party systems: sometimes the data isn’t even in the same system
One reason to separate customers and orders is that they might not live in the same system. If you’re building e-commerce, you might think, “I want customers and orders together behind my relational database so I can join the data and print an invoice or show an admin a grid of orders and customer details.” That sounds reasonable. But the real world often looks different.
We might decide the core value is sales, and instead of building a CRM ourselves, we buy one. We integrate with a CRM like Salesforce or a purpose-built CRM. In that case, customer data lives in an external system that is better suited for marketing, loyalty, support, and other customer interactions. Orders live in our order system. They are not in the same database.
So yes, customers and orders can be separate because the best tool for one part of the business is a third party system. We integrate with it instead of building it ourselves.
2. Large systems: database coupling becomes a maintenance nightmare
Another reason is that you do not want to end up with a giant database schema that is a turd pile and is really hard to change. The asker assumed keeping customers and orders together in one database would be easier because you could avoid multiple calls and joins. That may be true for simple systems. But context matters. If your system is large and highly coupled, sharing a single database makes change painful.
Imagine a massive schema with clients making all kinds of queries against it. Orders have a foreign key to customer. Customer has email. Now suppose you want to change how you represent email addresses, maybe allow multiple emails per customer. If that column is referenced in dozens, hundreds of places across multiple services or projects, you cannot simply change it. You will break integrations you do not even know exist.
Integration at the database level is hard to evolve. The degree of coupling matters. If you have a small system with a dozen or two dozen places in a single codebase, refactor and change is doable. If you have many parts, multiple repositories, or other systems reading from the same schema, it is a rats nest.
Also make the distinction between reads and writes. Much of the argument for keeping data together is about read composition. For example, showing an invoice with customer name and order details makes it convenient to have both in one place. But on the write side you might be persisting events. Your event store contains the series of events that produced state, and you might not store customer data inside that event store.
What solves this is a read model or projection built specifically for that read use case. You can project the data into the shape you need for invoices and admin grids. The read model can have customer information and order details combined for convenience, while the underlying write model and event store remain separate. This gives you the performance and simplicity for reads without forcing write side coupling.
3. Business alignment: different contexts, different behaviors
The root reason separate databases comes back to is business alignment. The original question was framed from a technology first perspective, which is the wrong starting point. Ask whether your architecture aligns with business needs or whether it imposes constraints on the business.
In a large system, what you do with customers in the context of orders is very different than what you do with customers in the context of marketing, support, or loyalty. A customer in the order context might represent billing information, shipping addresses, and order history. A customer in the marketing context might include segmentation, campaign preferences, and multiple contact points. They are the same person but they are treated differently. They have different behaviors and capabilities.
That difference in behavior and responsibility is why you might model them in separate databases or services. Each boundary owns its own data and its own rules. They may refer to the same customer by an identifier, but how the data is used, evolved, and scaled is different. Separation helps manage coupling and focus on cohesion within each bounded context.
So, when is separation justified?
- If you rely on a third-party system for customer data, separate the stores.
- If your system is large and evolving, and schema coupling prevents safe change, separate the data to reduce cross-system impact.
- If business domains treat the same entity differently, align your data boundaries to those business boundaries.
If, however, your system is small, low coupling, and you can change things in a single codebase without breaking other teams, keep them together. Do not add complexity for no reason. Context is king.
Manage coupling. Focus on cohesion.
All three reasons for separate databases point back to the same thing: manage coupling and align your architecture with the business. Yes, separating customers and orders adds complexity, but you only add that complexity when your system needs it. If you have a simple system, keep things simple. If you are in a large system, consider separate databases to protect your ability to change and scale.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.