Data Management and Storage
The three storage shapes
Block storage presents raw volumes to one compute instance with low latency (EBS, Azure managed disks, persistent disks) - used for boot volumes and databases. File storage offers shared POSIX/SMB semantics to many clients concurrently (EFS, Azure Files, Filestore). Object storage exposes an HTTP API over a flat namespace with rich metadata and effectively unlimited scale (S3, Blob Storage, Cloud Storage) - right for backups, media, logs and static sites, wrong for a database's random I/O.
Durability, availability, tiers
Durability is the probability data survives; availability is the percentage of time it can be read. Object stores advertise eleven nines of durability while availability sits near four nines - do not conflate them. Storage classes/tiers (hot, infrequent access, archive) trade retrieval latency and minimum storage duration for price, and lifecycle policies move objects automatically. Replication options span single-zone, multi-zone and cross-region. Snapshots are usually incremental and stored regionally; restoring creates a new volume. Snapshots are not a substitute for cross-region DR.
Data platforms
Relational databases give ACID transactions, joins and strong consistency, scaling mostly vertically with read replicas. NoSQL families (key-value, document, wide-column, graph) trade joins for horizontal scale and often eventual consistency. A data warehouse is columnar and optimised for analytics; a data lake stores raw files with schema-on-read; a lakehouse blends both. Caching layers cut latency and database load.
Trap: choosing object storage for workloads needing POSIX or block semantics, treating archive tiers as instantly retrievable, and assuming eventual consistency will not affect read-after-write logic.
Rule of thumb: classify by access pattern - random block I/O → block; concurrent shared files → file; massive unstructured objects over HTTP → object.