Introduction: Data Topology Is the Real Architecture
Most teams obsess over service boundaries, APIs, and deployment pipelines while quietly ignoring the most stubborn part of the system: data. That's a mistake. In distributed systems, your data topology is your architecture. It determines coupling, failure blast radius, scalability limits, and how fast teams can actually move once the honeymoon phase ends.
Here's the brutal truth: there is no “best” data topology. There are only trade-offs, and most organizations choose one accidentally—by inertia, legacy constraints, or cargo-culting microservices—rather than deliberately. The result is predictable: brittle systems, cross-team friction, and architectural rewrites disguised as “platform initiatives.”
This article compares three dominant data topologies used in distributed systems today: monolithic databases, domain-oriented shared databases, and database-per-service. We'll cut through the marketing narratives and talk about what actually happens in production systems, at scale, with real teams and real failure modes. The goal isn't purity—it's alignment between business needs, team structure, and operational reality.
What We Mean by “Data Topology” (And Why the Term Matters)
A data topology describes how data ownership, storage, and access are structured across a system, not just where tables live. It answers questions like: Who owns this data? Who is allowed to read or write it? How are changes propagated? What breaks when something fails?
This distinction matters because many teams confuse logical models with physical topology. You can have clean domain models and still sabotage yourself with a shared database. Conversely, you can run multiple databases and still be tightly coupled through synchronous cross-service queries. The topology is about power, boundaries, and dependency direction, not just infrastructure.
Martin Fowler has repeatedly emphasized that databases are the strongest form of coupling in software systems, stronger than APIs or shared libraries, because they encode assumptions that are hard to version and harder to unwind later. Once multiple teams depend on the same schema, change becomes political instead of technical. That's when architecture stops serving the business and starts slowing it down. Reference: Martin Fowler - “Microservices and the Database”
Monolithic Database: Centralized Power, Centralized Pain
The monolithic database is the default starting point for most systems, whether teams admit it or not. One database, one schema, many applications or modules reading and writing freely. Early on, it feels productive: joins are easy, transactions are cheap, and reporting is straightforward. There's a reason this approach refuses to die—it works well until it doesn't.
The real cost shows up when the system grows beyond a single team or when uptime and deployment independence start to matter. Schema changes become high-risk events. A single poorly optimized query can take down unrelated features. Scaling becomes asymmetric: you scale the database for the worst-case workload, not the average one. And forget about autonomous teams—everyone is coupled to the same release cadence, whether they like it or not.
That said, dismissing monolithic databases outright is architectural arrogance. For small teams, early-stage products, or systems with strong transactional requirements, a monolithic database is often the correct choice. The problem isn't the topology itself—it's staying on it long after it stopped fitting your organizational and operational reality. Reference: Kleppmann, “Designing Data-Intensive Applications”
Domain-Oriented Shared Databases: The Compromise That Ages Poorly
Domain-oriented shared databases attempt to improve on the monolith by introducing logical separation: schemas or databases per domain, often aligned with bounded contexts. On paper, this looks like a solid middle ground. In practice, it frequently becomes a half-measure that satisfies no one for long.
The core issue is shared ownership without shared accountability. Teams are told they “own” their schema, but other teams can still read from it directly. Over time, read dependencies turn into write dependencies, and “temporary” cross-domain joins become permanent. The database becomes an implicit integration layer, bypassing APIs and business rules entirely.
This topology often emerges in organizations transitioning toward microservices without fully committing to decentralization. It can buy time and reduce immediate friction, but it should be treated as a transitional state, not a destination. If left unchecked, it recreates monolithic coupling under a more complex operational surface, making the eventual migration harder, not easier. Reference: Eric Evans, “Domain-Driven Design”
Database-per-Service: Freedom With a Price Tag
Database-per-service is the topology most often associated with “true” microservices. Each service owns its data exclusively. No other service is allowed to read or write it directly. All integration happens through APIs or events. This enforces strong boundaries and enables independent scaling, deployment, and evolution.
Here's the part people don't like to talk about: this approach is operationally expensive and cognitively demanding. You trade simple joins for distributed consistency. You replace ACID transactions with eventual consistency and compensating actions. Debugging becomes harder. Data duplication becomes unavoidable. If your team isn't mature in observability, automation, and failure handling, this topology will amplify your weaknesses fast.
Used correctly, though, database-per-service aligns architecture with team autonomy. It scales organizationally as much as it scales technically. This is why companies like Netflix, Amazon, and Uber gravitate toward it—but they also invest heavily in platform tooling, data pipelines, and operational excellence to survive the complexity. Reference: Sam Newman, “Building Microservices”
Consistency, Transactions, and the Myth of “Just Use Events”
One of the biggest mental shifts when moving away from shared databases is letting go of global transactions. Two-phase commit looks tempting on whiteboards and disastrous in production. Distributed systems fail independently, and pretending otherwise leads to cascading outages and stuck workflows.
Event-driven architectures are often presented as the silver bullet. They aren't. Events introduce temporal coupling, schema evolution challenges, and replay complexity. They require discipline in versioning, idempotency, and monitoring. Without that, you're just moving the mess from the database to the message broker.
The honest approach is to design workflows around business invariants, not technical convenience. Some data must be strongly consistent. Some can tolerate delay. Good architectures make these decisions explicit instead of hiding them behind infrastructure magic. Reference: Kleppmann, “DDIA”, Chapters on Consistency and Transactions
Choosing the Right Topology: Align With Reality, Not Ideology
If there's one pattern that repeats across failed architectures, it's this: teams choose a data topology that reflects aspiration instead of capability. Microservices with database-per-service sound impressive, but without strong engineering discipline, they collapse under their own weight.
Ask uncomfortable questions early. How many teams do you have today—and in two years? How often do schemas change? Do you have strong CI/CD, observability, and on-call maturity? Are you optimizing for speed of change or reporting simplicity? There is no shame in choosing a simpler topology if it serves the business better right now.
Architecture is a continuous decision process, not a one-time declaration. The best systems evolve their data topology deliberately, with clear exit strategies and migration paths, instead of pretending today's choice will last forever.
The 80/20 of Data Topology Decisions
Most of the value comes from a few non-negotiable principles:
- Data ownership must be explicit and enforceable
- Avoid shared write access across team boundaries
- Design for change, not theoretical purity
- Operational maturity matters more than diagrams
- Treat data migrations as first-class architectural work
Get these right, and you avoid most large-scale failures. Ignore them, and no topology will save you.
Key Takeaways: Five Actions You Can Apply Immediately
- Inventory who reads and writes which data today—expect surprises
- Identify accidental shared schemas and undocumented dependencies
- Decide where strong consistency is truly required
- Align data ownership with team ownership, not org charts
- Document your data topology decisions as ADRs, not tribal knowledge
Conclusion: Architecture Is Accountability in Disguise
Data topology decisions are uncomfortable because they force organizations to confront how power, ownership, and responsibility are distributed. That's why they're often postponed or glossed over. But ignoring them doesn't make the consequences disappear—it just delays them until they're more expensive.
A well-chosen data topology won't make your system perfect. It will make trade-offs explicit, failures contained, and evolution possible. That's the real goal of distributed systems architecture: not elegance, but survivability.
If your data topology doesn't reflect how your teams actually work, it's already working against you.