Catalog
concept#Data#Platform#Architecture

Database

An abstract model for structured storage, querying, and management of persistent data across time and systems.

Databases are structured systems for storing, querying and managing persistent data.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Advanced

Technical context

ETL/ELT pipelinesBusiness intelligence and reporting toolsService APIs and application servers

Principles & goals

Data model first: define clear entities and relationshipsSeparation of storage and access layerProvision of consistency, backup and recovery strategies
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Data inconsistencies from improper transaction handling
  • Single point of failure without replication
  • Lack of governance leads to data quality issues
  • Define clear data ownership and governance
  • Perform schema changes in a controlled, migration-driven way
  • Regular backups and recovery testing

I/O & resources

  • Data model and entity definitions
  • Workload profiles (read/write ratios)
  • Security, compliance and privacy requirements
  • Persistent, queryable records
  • Backup and recovery artifacts
  • Monitoring metrics and operational indicators

Description

Databases are structured systems for storing, querying and managing persistent data. They provide models for organizing records, ensure consistency and durability, and enable efficient access patterns across applications. Databases underpin analytics, transactional systems and integration layers in modern software architectures.

✔

  • Structured, persistent storage with defined access mechanisms
  • Support for transactions and data integrity
  • Better foundation for analytics, reporting and integration

✖

  • Complexity in schema changes and migrations
  • Scaling limits depending on model and implementation
  • Operational effort for backup, recovery and performance tuning

  • Latency (p95)

    95th percentile of response times for representative queries.

  • Throughput (TPS)

    Transactions or queries per second under production load.

  • Recovery time objective (RTO)

    Time to recover after a failure.

Relational OLTP database (PostgreSQL)

Use of an ACID-capable database to handle orders and payments.

Columnar data warehouse

Providing analytical queries and aggregations for business intelligence.

NoSQL key‑value store for session data

Storing ephemeral session information with high read/write performance.

1

Gather requirements and design the data model

2

Choose database type and operational model (managed vs self‑hosted)

3

Set up backup, replication, monitoring and security measures

⚠️ Technical debt & bottlenecks

  • Old, non-migrated schemas and redundant fields
  • Leftover temporary indexes and queries
  • Insufficiently documented data models and mappings
I/O throughputNetwork latencySchema locking
  • Using a transactional database as primary data warehouse without adjustments
  • Storing large binaries directly in tables instead of specialized stores
  • Ignoring indexes and partitioning as data volume grows
  • Lack of planning for schema migrations and downtime
  • Insufficient monitoring leads to late discovery of performance issues
  • Relying on defaults without validating configuration
Data modeling and normalizationDatabase administration and backup/recoveryPerformance tuning and indexing
Data consistency and integrityScalability and performanceOperability, backup and recovery
  • • Regulatory requirements for data storage and access
  • • Hardware and infrastructure limits
  • • Compatibility with existing systems