Caching is the single highest-leverage performance tool available — and also one of the most common sources of production bugs. The decision isn’t just “should we cache?” — it’s where, how, and what the consistency implications are.
Cache Placement: Where Does the Cache Live? Each layer has different latency, scope, and invalidation complexity.
Client-Side Cache Browser cache, mobile app cache. Controlled by HTTP Cache-Control headers. The cheapest possible cache — zero server load.
NoSQL isn’t a single thing — it’s five different database families with fundamentally different data models, consistency guarantees, and use cases. Using the wrong family (or the wrong database within a family) is a common and costly mistake. Here’s how to think through each one.
Document Stores: MongoDB, DynamoDB, Firestore Data model: Each record is a self-contained JSON-like document. Collections of documents, each with its own structure.
Strengths:
Natural fit for entities with variable structure (product catalog, CMS content, user profiles with optional fields) Efficient reads when you need the whole entity (no joins — everything is in one document) Flexible schema for rapid iteration MongoDB:
SQL is SQL until it isn’t. When you’re making a database selection for a new service, the choice between PostgreSQL, MySQL, and SQL Server comes down to features, ecosystem, operational model, and political reality. Here’s how to reason through it.
PostgreSQL: The Default Choice for Most New Work Postgres is the right default for most new greenfield services at most companies. The reasons are concrete:
Feature set that matters in practice:
“Should we use SQL or NoSQL?” is one of the most common — and most misunderstood — architecture questions. Teams default to NoSQL because it sounds modern or scalable, or to SQL because it’s familiar. Neither is the right reason. The decision should come from your data’s shape, consistency requirements, and access patterns.
When Relational Wins Use a relational database when:
1. Your data has relationships you’ll query across. If you regularly join orders to users to products to promotions, a relational model with foreign keys and proper indexes is cleaner and faster than assembling that from multiple document fetches or denormalized data.
