Many of us have worked on a database in some way. We might write the code to build it, or we may support it in production, but often we see it evolve over time to meet new needs and goals. Sometimes it's a smooth journey, but other times it can be bumpy. In any case, many of us don't end up with our designs being documented in academic papers.

I ran across an interesting list from someone that Facebook that built a control plane system (Delos) and write a post about things they learned from building a database. Really, this is a storage system that helps infrastructure teams manage their environment. Since most of us don't work at Facebook scale (billions of users), we might not care, but the list was something to read, as it's broken into various categories. Maybe this is more a list of things you should think about when building software in general, but a few items stuck out to me.

First, the list opens with "keep customers happy; else the rest of this document doesn't matter." That's been one of my key mantras throughout my career. My thoughts are less important than the customers, and I need to keep that priority straight. This helps me to ensure I'm being effective in their eyes, not mine, and helps me decide when I compromise the way I might design and implement something.

The second thing from the Customers sections say "read their code," with the reminder that the customer might not really understand what they want or need, and often just express their use case poorly. I think this might be extremely important for anyone building software. Read between the lines.

The one database item that I think really can matter is linked to storage systems, but I think it applies to databases. "...bias heavily towards consistency and durability rather than availability.." The reasoning being these are harder to fix. While database platforms often handle this well, we often don't take advantage of PKs, FKs, and other items that help ensure consistency in our system. Too often I see people trying to retrofit these items in later when the data is a mess. I really worry about this in systems built on NoSQL platforms.

I like the list, and also the deployment item that notes critical checks should be in the deployment. We want to know if we've made a mistake early on, before our customers notice. I might stress for databases that we often want this done in QA or staging. After all, if something breaks in the data, it can be very difficult to fix.