When designing a new system or feature, it’s easy to get bogged down on schema design. In this article I will share a neat trick that has paid dividends over my career.
All too often, I see teams reach for SQL or MongoDB as their only choice for data storage. Sure, no one’s getting fired for choosing SQL. But what if I told you there’s a simpler, faster, and cheaper way to start?
A simple storage layer can moderately speed up early development by reusing data-layer code and avoiding costs related to churn in schema design and migrations. Churn will happen anyway; let the code deal with it as long as possible. Better to avoid dealing with changes in two places.
It can feel strange to design with a Key-Value pattern first, especially if you’re used to designing systems with object hierarchies or Entity Relationship Diagrams and directly implementing them in SQL.
You’ve probably used key-value patterns before! They are everywhere, from configs and URLs to S3-style Object Storage! Every time you deal with data via a unique ID value, guess what? Another Key-value pattern! (Though not necessarily a KV Store.)