Data Storage

Basic System Design
≈ 2 min read

Data outlives an individual request

An application can be stateless, but the system itself almost always keeps state: users, orders, events, files, settings, and other data. That is why choosing storage is not a question of “which database is faster,” but a decision about which properties of the data and workload the system must support.

In this section, we will review the main storage types and learn to choose them from requirements rather than technology popularity.

What we will cover

  • Storage Requirements. We will define data volume, read and write patterns, latency, availability, consistency, and retention requirements.
  • SQL vs NoSQL. We will see which problems fit the relational model naturally and when another data model is more useful.
  • Relational Databases. We will look at tables, relationships, constraints, and transactions as tools for maintaining structured data.
  • Key-Value Stores. We will examine the “key → value” model and scenarios where simple key lookup matters more than complex queries.
  • Document Databases. We will explore storing aggregated objects as documents and using a flexible record structure.
  • Column Databases. We will see why column-oriented storage is convenient for analytics and reading a small set of fields from a large data volume.
  • Object Storage. We will understand where to keep large binary objects such as images, videos, archives, and backups.
  • Choosing Storage. We will bring requirements and constraints together and learn to select an appropriate storage type for a particular part of the system.

The topics move from requirements to concrete storage models and finish with selection. This makes it easier not to bind a problem to one technology too early and to see that different data can live in different stores in a real system.

There is no universal database. Good storage is storage whose properties match the requirements of specific data and operations.