In my first post in this pseudo-series, we covered more of the theory and organisational practices around building and operating a database-as-a-service platform. In this post, I’ll cover some of the more technical aspects of this that I think are worth considering, drawn from my own experience.

So you’ve made the decision to build a Database-as-a-Service product (or something similar). As a result, you are making state and coordination your problem. Here are some things I’ve learned to keep in mind as you embark on this project, in no particular order (other than the first). This is a long one, so a table of contents is provided to skip around to the points that interest you.

Corporate legibility is the art of making tasks, and their outcomes, easier to understand for those not directly involved. I’ll help you understand why this is an important thing to be aware of and how to use it to help your career.

Rice cookers are fascinating machines. I’ve owned one for years, as rice is a significant part of my regular diet, and it completely removes the stress of preparing rice. They also operate on a simple principle that can help us operate cloud infrastructure – the control loop.

One of the hardest things we do, as humans, is try and communicate what is going on in our minds to each other. With significant room for misunderstanding, biases, assumptions and cultural differences, communicating with other engineers (or to stakeholders) appears fraught. However, there are tools we can leverage to make ourselves understood, and to smooth the passage of information to makes sure it gets to the right people at the right time.