Boringly stable

Post launch, we’ve been in constant pursuit of making 3B's performance and infrastructure as boring and stable as possible.

The main focus has been chasing down every sentry exception and bug that has been filed. What’s surprised us about this is practically all of them have had a real and satisfying root cause. So often, an innocuous, seemingly random or transient one has turned out to point to a clear and discrete flaw in our software. Interestingly, we have found locating these root causes to require a lot of creative energy and to be quite a lot harder than building features now. This is making us double down on prioritizing sentry exception investigations and bug fixes, so that we can continue to discover these flaws that are hard to find.

Our theme of boring stability didn't just stop with obsessing over exceptions and bugs. We built row level security (RLS) for tenants, which means tenant isolation is now enforced at the database layer rather than just within the application code, so any bugs in our application code cannot leak customer data. We are BIG fans of Rust as a team, so we rewrote our core services in Rust for more predictable scaling and easier tracing for future bugs. And last but certainly not least, we shipped v1 of Blobstore, which is our very boring foundation that all storage in 3B is built upon. Shipping v1 actually unlocks future work that is the opposite of boring, such as better monitoring features, search and indexing, migrations, and branch forking at the filesystem layer, so 3B forks your database for free.

While a lot of this hard work is invisible, we also shipped unit tests, so your workflows can be as boring and stable as we are. Implement them in workflows so new changes don’t unintentionally break existing functionality.