Data Disintegrators

Core Idea

Data disintegrators are architectural forces that drive the separation of data schemas and databases across service boundaries in distributed architectures.

Definition

Data disintegrators are architectural forces that drive the separation of data schemas and databases across service boundaries. These forces represent requirements or constraints that benefit from data independence—where each service owns and manages its own data rather than sharing databases. Data disintegrators oppose Data-Integrators (forces favoring shared databases), creating trade-offs architects must analyze.

Key Characteristics

• Service change independence: Services evolving data models at different rates benefit from separated databases, enabling independent schema evolution
• Distinct scalability profiles: Different read/write patterns or data volumes enable independent scaling strategies
• Fault isolation boundaries: Separate databases prevent failures from cascading across services, containing blast radius to single domains
• Security and compliance domains: Different data sensitivity levels enable targeted access controls and compliance auditing per domain
• Technology diversity requirements: Different access patterns favor different database types—document stores, graph databases, time-series
• Team ownership and autonomy: Independent data ownership aligns with domain-driven design, allowing teams to modify schemas without cross-team coordination

Example

Media streaming: Isolating user play events (high-volume time-series in Cassandra) from user profiles (structured relational in PostgreSQL)—each scaled and evolved independently without coordination.

Why It Matters

Data disintegrators provide a framework for evidence-based decisions about database separation, transforming “database per service” from dogma into nuanced trade-off analysis. Without this framework, teams either prematurely split databases (introducing distributed transaction complexity) or maintain shared databases too long (creating coupling and deployment bottlenecks).

Data separation introduces real costs—eventual consistency, distributed transactions, cross-service queries, operational overhead. These costs are only justified when specific disintegrator forces create tangible value.

Related Concepts

• Architectural-Modularity-Drivers - Higher-level forces driving system decomposition
• Granularity-Disintegrators - Parallel forces for service-level decomposition
• Bounded-Context - Domain-driven design boundaries that often align with data separation
• Data-Integrators - Opposing forces favoring shared databases
• Data-Ownership-Patterns - Implementation patterns when data separates
• Distributed-Transactions - Challenge introduced by data separation
• Saga-Pattern - Transaction management across separated databases
• Eventual-Consistency - Consistency model required when data separates
• Service-Granularity - Service sizing decisions influenced by data ownership
• Fault-Tolerance - Benefit achieved through data isolation
• Scalability - Driver for independent database scaling strategies
• Software Architecture - The Hard Parts - Ford, Richards, Sadalage & Dehghani - 2022 - Primary source introducing framework
• Data-Mesh - Architectural approach embracing data separation at scale

Sources

• Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 978-1-492-08689-5. Chapter 8: Data Ownership and Distributed Transactions. Available: https://www.oreilly.com/library/view/software-architecture-the/9781492086888/

• Richardson, Chris (2019). “Pattern: Database per service.” Microservices.io. Available: https://microservices.io/patterns/data/database-per-service.html

• Dehghani, Zhamak (2019). “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh.” Martin Fowler’s Blog. Available: https://martinfowler.com/articles/data-monolith-to-mesh.html

• Stopford, Ben (2018). “The Data Dichotomy: Rethinking the Way We Treat Data and Services.” Confluent Blog. Available: https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/

• Newman, Sam (2021). Building Microservices: Designing Fine-Grained Systems, 2nd Edition. O’Reilly Media. ISBN: 978-1-492-03402-5.

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.