Large technology platforms store an enormous variety of information. User accounts, social relationships, orders, messages, videos, search indexes, activity events, and analytical data all have different access patterns and reliability requirements.
At a small scale, much of this information can live in one relational database. At a global scale, that database eventually becomes a bottleneck. Storage must be distributed across many machines, replicated between locations, cached for fast access, and separated according to how the data is used.
In this post, we’ll design a general data-storage architecture for a large technology platform. The objective is not to select one database for everything, but to understand how several storage systems can work together safely.
A system design interview may begin with a broad prompt:
Design the data-storage platform for a large technology company.
Before designing anything, we need to define what the platform stores. “Big data” is not one type of data, and no single database is ideal for every workload.
For this design, the platform will support structured account data, relationships between users, user-generated content, large media files, high-volume activity events, search, and analytical reporting.
The platform must handle billions of records, millions of requests per second, and deployments across several geographic regions. It should remain available when machines fail while protecting important data against corruption or loss.
The central design decision is to match each workload with the appropriate storage model. Structured transactions, large files, search queries, temporary cached values, and analytics should not all be forced into the same system.
The platform must store core records such as users, settings, permissions, products, posts, or orders. These records are structured and may require constraints, transactions, and reliable updates.
It must also support relationships. Depending on the product, these could include friendships, followers, group memberships, account hierarchies, or links between customers and orders.
Large binary objects such as images, videos, documents, and backups need durable storage but do not benefit from relational queries. The database should hold their metadata and references rather than the files themselves.
The platform also generates a continuous stream of events. Page views, clicks, searches, application logs, security events, and changes to business records may produce billions of entries each day.
Search and analytics introduce additional requirements. Users expect fast full-text search, while internal teams need to aggregate months or years of historical information without slowing down the operational databases.
The non-functional requirements include high availability, horizontal scalability, predictable latency, disaster recovery, and strong security. Some data requires immediate consistency, while other information can be slightly stale.
The design will focus on the shared storage architecture. Detailed product-specific business logic, user interfaces, and machine-learning models remain outside the initial scope.
Before selecting databases, classify the information according to how it is written and read.
Account information is usually accessed by a stable identifier and updated relatively infrequently. Orders and payments require transactions and strong correctness. Social feeds and activity timelines involve very high read volumes and may be precomputed.
Messages and event streams are usually append-heavy. Search queries need text indexes rather than ordinary database lookups. Media files are large and mostly immutable, while analytical queries scan and aggregate huge datasets.
The expected access pattern is more important than the shape of the data alone. Two services may store records that look similar but need different databases because one performs transactional updates and the other serves billions of low-latency reads.
A strong design starts with the queries the system must support and works backwards towards storage.
Suppose the platform has one billion registered users and 200 million daily active users. If each active user generates 100 operational requests per day, the system handles approximately 20 billion requests daily.
That is an average of roughly 230,000 requests per second, with peaks potentially reaching several million requests per second.
If each active user generates 200 behavioural or operational events per day, the analytics pipeline receives 40 billion events. Even at an average of only 500 bytes per compressed event, this creates approximately 20 terabytes of new event data each day before replication.
Media is likely to dominate storage capacity. If ten million files averaging five megabytes are uploaded daily, the platform adds around 50 terabytes of media each day.
These estimates show why the platform cannot depend on one database cluster. It needs partitioning, replication, multiple storage tiers, and clear retention policies.
Each application service should own its data. The User Service owns user profiles, the Order Service owns orders, and the Content Service owns posts and their metadata.
Other services should not modify another service’s database directly. They should use a defined API or consume published events.
This ownership prevents accidental coupling between schemas and allows services to evolve independently. It also makes it clear which system contains the authoritative version of a record.
Some data will appear in several places. A product record may exist in the transactional database, cache, search index, analytics warehouse, and recommendation store. These are not five equal sources of truth.
The transactional store remains authoritative. The other representations are read models designed for particular access patterns and can be rebuilt from the source data or its change history.
The platform uses several specialised storage systems behind its application services:
Web and Mobile Clients
│
↓
API Gateway
│
↓
Application Services
│
├──→ Distributed Cache
├──→ Relational Databases
├──→ Distributed Key-Value Store
├──→ Object Storage → CDN
└──→ Event Stream
│
┌───────┼────────┐
↓ ↓ ↓
Search Data Lake Analytics
Index WarehouseApplication services contain business logic and provide the boundary around each dataset. They decide which records require a transaction, which values can be cached, and which changes should produce events.
Services can scale horizontally because requests are distributed across multiple instances. They remain mostly stateless, with durable information stored in the appropriate data systems.
Relational databases store structured records that require constraints, transactions, and predictable relationships.
Suitable workloads include user accounts, orders, payments, permissions, subscriptions, and configuration. These systems provide strong guarantees when several related changes must succeed or fail together.
At large scale, the platform uses multiple database clusters rather than one global relational database. Data is divided by service and then partitioned further as individual datasets grow.
High-volume workloads that primarily access data by key can use a distributed key-value or wide-column store.
Examples include timelines, session state, counters, message metadata, feature state, and precomputed recommendations. These systems can distribute data across many nodes and provide predictable low-latency lookups.
The reduced support for joins and complex transactions means that records are often denormalised around the queries the application needs to perform.
Images, videos, documents, archives, and backups are stored in distributed object storage.
The operational database stores an object identifier and metadata such as ownership, file type, size, creation time, and processing status. Clients upload and download the large content through dedicated media services rather than the primary application database.
Frequently accessed objects are distributed through a CDN, reducing latency and origin traffic.
A distributed in-memory cache stores frequently requested data and expensive query results.
Caching protects databases from repeated reads and reduces response time. It can be used for profiles, configuration, sessions, popular content, permissions, and precomputed pages.
The cache is not normally the only copy of important data. If it becomes unavailable, the system should still be able to retrieve authoritative information from durable storage, although at reduced performance.
When application data changes, services publish events into a durable, partitioned stream.
These events allow search, analytics, notifications, fraud detection, and machine-learning pipelines to react without being directly coupled to the original database transaction.
The stream also provides a record of changes that can be replayed to rebuild downstream systems.
A dedicated search system stores a read-optimised representation of searchable content.
It supports full-text queries, ranking, filtering, autocomplete, and other operations that would be inefficient in the primary transactional databases.
Search indexes are updated asynchronously, so they may briefly lag behind the source of truth. The application should retrieve authoritative data before completing sensitive operations.
Raw events and large historical datasets are stored in a data lake using inexpensive object storage. This provides durable, long-term retention for analytics, model training, and future processing.
Cleaned and structured data can then be loaded into an analytical warehouse. The warehouse is designed for aggregations and scans rather than low-latency transactional updates.
Separating operational and analytical workloads prevents a large report from slowing down customer-facing applications.
When a service changes an authoritative record, other systems may need to receive the update.
One option is to publish an event directly after committing the database transaction. However, the service could crash after saving the record but before publishing the event.
The transactional outbox pattern addresses this problem. The service writes the business change and an outgoing event into the same database transaction. A background publisher reads the outbox and reliably sends its events to the streaming platform.
Change data capture provides another option. A connector reads the database’s transaction log and converts committed changes into events without requiring the application to publish them manually.
Downstream consumers use those events to update caches, search indexes, analytical tables, and other read models.
These consumers should be idempotent because an event may be delivered more than once. Reprocessing the same change must not corrupt the destination.
The most important challenges are partitioning, replication, consistency, caching, and managing data across several storage systems.
A dataset that no longer fits on one server must be divided into partitions or shards.
The partition key determines where each record is stored. A good key distributes storage and traffic evenly while supporting the most common queries.
User ID is a common choice for user-centred data. Requests for one user can be routed directly to the correct shard, and the platform can add more shards as the number of users grows.
However, not every query follows one user. A social feed may combine posts from hundreds of accounts, while an organisation-level report may access records belonging to many users.
Cross-shard queries are slower and harder to coordinate. The data model may need additional indexes or precomputed read models to support them efficiently.
Time is another possible partition key for logs and events. Recent writes can be placed into current time partitions, while older partitions become read-only and move into cheaper storage. Pure time-based partitioning can create hot partitions because every new write targets the same place.
A compound key or hash prefix can spread current writes across several partitions while preserving a useful time range within each partition.
Even a well-distributed dataset can contain unexpectedly popular keys.
A celebrity profile, viral post, live event, or widely used configuration record may receive far more traffic than neighbouring records. Adding more shards does not solve the problem if every request still targets the same key.
Caching is the first defence against hot reads. Popular values can be replicated across cache nodes and CDN locations.
Hot writes are more difficult. Counters can sometimes be split into several partial counters and combined when read. Other operations may require one authoritative writer and therefore have a natural throughput limit.
The architecture should detect hot keys and isolate them before they affect unrelated traffic.
Partitioning increases capacity, while replication improves availability and durability.
Each shard can have a primary replica that accepts writes and one or more secondary replicas. If the primary fails, a secondary can take over.
Synchronous replication confirms a write only after multiple replicas have stored it. This reduces the risk of data loss but increases latency and may reduce availability during network failures.
Asynchronous replication responds sooner but can lose the latest acknowledged changes if the primary fails before its replicas catch up.
The correct choice depends on the data. A payment record may justify synchronous replication, while a view counter may accept weaker durability for lower latency.
Read replicas can scale read traffic, but they may return stale values. Applications should avoid replicas when a workflow requires read-after-write consistency.
Consistency should be decided for each operation rather than for the entire platform.
Financial transactions, username ownership, inventory reservations, and access-control changes usually require strong consistency. A stale result in these areas could cause duplicate ownership, overselling, or unauthorised access.
Activity feeds, view counts, recommendations, analytics, and search indexes can often be eventually consistent. Small delays are acceptable if they allow the system to remain responsive and available.
Some workloads need consistency within a smaller boundary. Messages may require ordering within one conversation but not across every conversation. Orders may require transactions within one customer or merchant partition without requiring a global transaction.
Choosing the narrowest useful consistency boundary improves scalability.
A business operation may involve several services and databases. Placing an order could reserve inventory, create an order, charge a payment method, and request fulfilment.
A traditional database transaction cannot easily span these independent systems.
The platform can use a saga, dividing the workflow into local transactions. If a later step fails, compensating actions reverse earlier work where possible. A failed payment may release reserved inventory, while a cancelled order may trigger a refund.
Each step should be idempotent because messages and commands may be retried. The workflow also needs a durable state record so it can recover after a process failure.
Distributed transactions should be avoided when one service can safely own the entire consistency boundary. Splitting tightly connected data across services creates complexity that infrastructure cannot completely hide.
The cache-aside pattern is commonly used for application data.
The application checks the cache first. If the value is missing, it retrieves the record from the database and places it in the cache for future requests.
When data changes, the service can invalidate the corresponding cache entry or replace it with the new value. Expiry times provide an additional safety mechanism.
Invalidation events may be delayed or lost, so the system must decide how long stale data is acceptable. Security-sensitive values may require a shorter expiry or an authoritative database check.
Cache keys should include all relevant context, such as tenant, region, language, permissions, or record version. An incomplete cache key can expose incorrect or unauthorised data.
The system must also protect against cache stampedes. When a popular entry expires, many requests may attempt to rebuild it simultaneously. Request coalescing, staggered expiry times, and background refreshes can reduce this load.
Large platforms frequently store relationships such as followers, friends, memberships, and recommendations.
A specialised graph database can support complex graph traversal, but it is not always necessary. Many high-volume relationship queries are simple lookups such as “who does this user follow?” or “is this user a member of this group?”
These relationships can be stored in partitioned adjacency lists. One index stores outgoing relationships by source identifier, while another supports reverse queries by destination identifier.
For example, following a user may create one record for the accounts a person follows and another for that person’s followers. These copies must be updated reliably, often through an event or local transaction.
Complex offline graph analysis can run separately in the analytics platform rather than placing expensive multi-hop queries on the operational database.
Clients should upload large files directly to object storage using short-lived, authorised upload URLs.
After the upload completes, a media-processing pipeline can validate the file, extract metadata, create thumbnails, transcode video, and scan content according to the platform’s requirements.
The media record moves through states such as uploaded, processing, available, or rejected. Application records should not expose an unfinished object as fully available.
Object storage automatically provides replication and durability, but the platform still needs lifecycle rules. Frequently accessed media can remain in fast storage, while older or rarely accessed content moves to less expensive tiers.
Deleting media requires more than removing its database reference. Cached CDN copies, derived formats, backups, and analytical references must also follow the platform’s retention and privacy policies.
A global platform needs to decide where each dataset is written and how it is replicated.
One approach assigns every record or tenant a home region. Writes are routed to that region, where one authoritative copy provides consistency. Other regions maintain replicas for disaster recovery and local reads.
This is simpler than allowing every region to write the same record, but users far from the home region experience additional write latency.
Active-active storage allows writes in several regions. It improves local availability but introduces conflict resolution. This works best for data whose updates can be merged safely, such as some counters, preferences, and collaborative structures.
It is much harder for payments, ownership, or inventory. These records may still require a single leader or consensus across regions.
Regional placement may also be affected by privacy and data-residency requirements. The routing layer should know where each tenant or record is allowed to live.
Every storage system must assume that disks, machines, networks, zones, and occasionally entire regions will fail.
Replicas should be distributed across independent failure domains. Automatic failover can reduce downtime, but it must prevent two replicas from accepting conflicting writes.
Backups provide protection against problems that replication cannot solve. A software defect or accidental deletion can be copied immediately to every replica. Point-in-time recovery allows the platform to restore data from before the damaging operation.
Backups must be encrypted, retained according to policy, and tested regularly. An untested backup is only an assumption.
Recovery objectives should be defined for each dataset. The recovery point objective describes how much recent data can be lost, while the recovery time objective describes how long restoration may take.
Not every dataset requires the same target. Payment data needs much stronger recovery guarantees than a rebuildable cache or search index.
Data should be encrypted in transit and at rest. Encryption keys should be managed separately from the stored data and rotated according to policy.
Services and users should receive only the permissions they require. Administrative access to production databases must be restricted, audited, and used through controlled tools.
Sensitive fields may require additional application-level encryption or tokenisation. Personal data should not appear unnecessarily in logs, event streams, or analytics datasets.
Retention policies determine how long each class of data is stored. Some information may need to be retained for legal or financial reasons, while privacy regulations may require other records to be deleted.
Deletion in a distributed system is a workflow rather than a single database command. The platform must remove or anonymise data across transactional stores, caches, indexes, data lakes, derived tables, and backups according to the applicable policy.
A data catalogue can record ownership, classification, lineage, retention, and approved usage. This becomes increasingly important as the number of services and datasets grows.
Each storage system should expose measurements related to capacity, latency, availability, and correctness.
Useful metrics include query latency, error rates, replication delay, disk usage, cache hit rate, partition size, connection saturation, event backlog, backup status, and restore duration.
The platform should monitor data correctness as well as infrastructure health. Missing events, duplicate records, inconsistent indexes, and delayed deletion workflows may not cause a server alarm but can still affect users.
Data lineage and correlation identifiers help engineers follow a record from its source database into caches, streams, indexes, and analytical tables.
Alerts should identify hot partitions, uneven shard distribution, replica lag, growing queues, failing backups, and storage systems approaching their capacity limits.
During the interview, begin by classifying the data rather than naming databases immediately. Explain which information is transactional, append-only, cacheable, searchable, analytical, or stored as large objects.
Next, present the high-level architecture. Application services own their authoritative data, while caches, object storage, key-value stores, search indexes, event streams, and analytical systems support specialised workloads.
Walk through an important data change. A service commits a record and an outbox event, which is published to the event stream. Downstream consumers update the search index, analytics platform, and any relevant read models.
The deep dive should focus on partitioning and consistency. Explain how the partition key supports common queries, how replicas handle failure, and which operations can tolerate stale data.
Be clear about the trade-offs. Stronger consistency increases coordination and latency. More denormalisation improves reads but makes updates and recovery more complicated. Shared storage reduces cost but increases the need for isolation and workload controls.
Finish by identifying the source of truth for each type of data. Search indexes, caches, and analytical tables are valuable, but they should not silently become competing authorities.
A common mistake is selecting a database before understanding the access patterns. Storage technology should follow the required queries, consistency, scale, and operational constraints.
Another mistake is assuming that one database must handle every workload. Transaction processing, full-text search, large objects, caching, and analytics have fundamentally different requirements.
Candidates may also introduce sharding without explaining the partition key. Saying that a database is sharded is incomplete unless the design shows how requests reach the correct shard and how cross-shard queries are handled.
Replication is sometimes confused with backup. Replication helps the system survive infrastructure failure, but it also copies accidental deletion and corruption. Independent backups and tested restoration are still required.
Finally, eventual consistency should not be used as a vague answer to every distributed problem. The design should identify exactly which data may be stale, for how long, and what users experience during that delay.
The platform could automate shard placement and rebalancing as datasets grow. Large tenants or unusually hot keys could move to dedicated partitions without changing the public API.
Storage classes could become more intelligent. Access patterns could automatically move older objects and records into less expensive tiers while keeping indexes or summaries available for fast discovery.
Schema management could be standardised across services. Automated compatibility checks would prevent an event producer from publishing a change that breaks downstream consumers.
The platform could also provide a unified data-access layer for encryption, tenant routing, retries, auditing, and observability. This would reduce duplicated infrastructure logic while still allowing services to own their schemas.
More advanced integrity systems could compare authoritative databases with search indexes, analytical tables, and object metadata. Differences could be repaired automatically when safe or sent for investigation.
Multi-region placement could eventually adapt to user location, regulatory requirements, and measured traffic. These improvements should preserve clear ownership and avoid introducing multi-region writes where their complexity is not justified.
Big Tech data storage is not one enormous database. It is a collection of specialised systems connected through clear ownership boundaries and reliable data pipelines.
Relational databases store structured and transactional records. Distributed key-value stores support high-volume access by key. Object storage holds large files, caches accelerate frequent reads, and event streams distribute changes.
Search indexes provide fast discovery, while data lakes and analytical warehouses support reporting, experimentation, and machine learning without affecting customer-facing databases.
Partitioning distributes capacity, and replication protects availability. The partition key, consistency model, and replication strategy must match the access patterns and importance of each dataset.
The authoritative record should remain clearly defined even when data appears in several systems. Caches, indexes, and analytical models are derived representations rather than competing sources of truth.
The most important lesson is that large-scale storage design begins with the data and its behaviour. Once the access patterns, consistency requirements, and failure scenarios are understood, the appropriate technologies and architecture become much easier to choose.