SQL, NoSQL, Caches, Search, and Object Storage
Compare storage options and learn why real systems often use multiple stores for different access patterns.
Key-Value, Wide-Column, Graph, and Time-Series Stores
NoSQL is a broad family, not one data model. Key-value stores optimize lookup by key; wide-column stores distribute large sparse datasets across partition keys; graph databases represent relationships and traversals; time-series stores optimize timestamped measurements and retention/downsampling.
Each model has a preferred query shape. A key-value store is excellent for sessionId → session, but poor for arbitrary joins unless extra structures are maintained. A graph store can simplify multi-hop relationship queries, while a relational schema may remain better for conventional transactional records.
Before selecting a specialized database, define partition keys, query patterns, retention, consistency, operational expertise, and migration cost. Specialized stores can deliver substantial benefits, but they increase the number of systems to secure, monitor, back up, and recover.
- Choose a database for dominant access patterns.
- NoSQL does not mean schema-free or automatically scalable.
- Every additional datastore adds operational and recovery responsibilities.
What is a common responsibility of a cache-aside application?
Caching Strategies and Cache Invalidation
A cache stores reusable results closer to the consumer to reduce latency and backend load. Common patterns include cache-aside, read-through, write-through, and write-behind. In cache-aside, the application checks the cache, loads a miss from the source, then populates the cache.
Cache invalidation is difficult because cached data can outlive the source state. Use TTLs, versioned keys, explicit invalidation, or event-driven updates according to the consistency requirement. A short TTL limits staleness but increases backend traffic; a long TTL improves hit rate but may serve older data longer.
Protect against cache stampedes when many requests miss the same hot key. Techniques include request coalescing, jittered TTLs, stale-while-revalidate, and controlled refresh. Also protect against cache penetration from repeated requests for nonexistent keys and hot-key overload where one key receives disproportionate traffic.
- A cache is a performance layer, not automatically the source of truth.
- Define acceptable staleness and invalidation behavior.
- Plan for stampedes, hot keys, and cache outages.
Search Indexes, Object Storage, and CDNs
Search engines build inverted indexes and other structures for text relevance, filtering, facets, and ranking. They are usually derived views rather than the authoritative record store. Updates may be eventually consistent, so a newly created record may not appear immediately in search.
Object storage is designed for large blobs such as images, videos, archives, and backups. Store metadata and ownership in a database and keep the blob in object storage; use signed URLs or controlled gateways for uploads and downloads. Validate file type, size, ownership, and scanning status rather than trusting a filename.
A CDN caches suitable static or cacheable content at edge locations. Versioned asset names make long cache lifetimes safer. For private content, use authorization-aware signed URLs and carefully scoped expiration; never assume that an obscure URL is access control.
- Search indexes are often derived and eventually consistent.
- Object storage is a better fit than database rows for large blobs.
- Signed URLs need narrow permissions and expiry.