IuriiO Notebook
  • Broken Code Notebook
  • Architecture and Design
    • Architectural Decision Records
    • Trade-off Analysis
    • Data Decomposition Drivers
    • Selecting a Database Type
    • Service Granularity
    • Consumer-driven Contracts
  • Cloud
    • AWS
      • Resources
      • Compute
        • EC2
        • Batch
        • ECS & ECR
        • Elastic Beanstalk
      • Storage & Data Management
        • S3
        • Storage Gateway
        • RDS
        • DynamoDB
        • ElastiCache
        • Redshift
        • EBS
        • EFS
        • FSx
        • Snowball
        • Athena
        • Encryption and Downtime
        • Untitled
      • Security & Compliance
        • IAM
        • Web Identity Federation
        • Organizations
        • Service Catalog
        • Tags and Resource Groups
        • STS
        • KMS
        • GuardDuty
        • Compliance
        • Marketplace Security Products
        • DDOS
        • Compliance Frameworks
      • High Availability
        • Global Infrastructure
        • Disaster recovery
        • Elastic Load Balancers
        • Untitled
      • Monitoring & Reporting
        • Cost Explorer
        • CloudWatch
        • Systems Manager
        • Config
        • CloudTrail
        • Cost control
        • Untitled
      • Networking
        • Networking 101
        • Route53
        • CloudFront
        • VPC
        • DirectConnect
        • WAF
        • Shield
        • Global Accelerator
      • Deployment & Provisioning
        • Untitled
        • Untitled
      • Automation & Optimization
        • CloudFormation
          • Links
          • Github resources
          • YAML 101
          • Videos
        • OpsWorks
        • Untitled
      • Application Services
        • SQS
        • SWF
        • SNS
        • Untitled
      • Serverless
        • Lambda
        • API Gateway
        • DynamoDB
        • SAM
        • Untitled
      • Well-Architected Framework
    • Azure
      • Tools
      • Organization & Management
      • Authentication & Authorization
      • Compute
      • Networking
      • Storage
      • Databases
      • Security
      • Privacy, Compliance & Trust
      • Cost Management
  • Containers & Services
    • Docker
      • Useful Links
      • Containers
      • Images
      • Dockerfile
      • System
      • Compose
      • Swarm
      • Docker & NodeJS
    • Kubernetes
      • Useful Links
      • Introduction
      • Getting started
      • Exposing containers
      • Kubernetes Management Techniques
        • Declarative YAML
      • Labels and Annotations
      • Storage in Kubernetes
      • Ingress Controller
      • CRD's and The Operator Pattern
      • Kubernetes Dashboard
      • Kubectl Namespaces and Context
  • Frontend
    • Resources
    • Design
      • Search experience
Powered by GitBook
On this page

Was this helpful?

  1. Architecture and Design

Data Decomposition Drivers

Breaking apart a monolytic database can be a daunting task, and as such it is important to understand if (and when) a database should be decomposed.

Architects can justify a data decomposition effort by understanding and analyzing data disintegrators (drivers that justify breaking apart data) and data integrators (drivers that justify keeping the data together). Striving for a balance between these two forces and analysing the trade-offs of each is the key to getting the data granularity right.

Data Disintegrators

Data disintegration drivers provide answers and justifications for the question "when should I consider breaking apart my data?". The main drivers area as follows:

  • Change control: How many services are impacted by a database change?

  • Connection management: Can my database handle the connection needed from multiple distributed services?

  • Scalability: Can the database scale to meet the demands of the services accessing it?

  • Fault tolerance: How many services are impacted by a database crash or maintenance downtime?

  • Architectural quanta: Is a single shared database forcing me into an undesirable single architecture quantum?

  • Database type optimization: Can I optimize my data by using multiple database types?

Data Integrators

Data integrators do the opposite of the data disintegrators. These drivers provide answers and justifications for the question: "when should I consider putting data back together". Along with data disintegrators, they provide the balance and trade-offs for analyzing when to break apart data and when not to.

The two main integration drivers for putting data back together are the following:

  • Data relationship: Are there foreign keys, triggers, or views that form a close relationship between the tables?

  • Database transactions: Is a single transactional unit of work necessary to ensure data integrity and consistency?

PreviousTrade-off AnalysisNextSelecting a Database Type

Last updated 3 years ago

Was this helpful?