Hacker News Reader

Comment by catlifeonmars | Hacker News Reader

I came here to say this too. Most bugs I run into are when databases schema versions interact with multiple software versions. If you are a low availability service, you can just take down the service and update the schema atomically, but 90% of the time you actually need to write backwards compatible migrations and forwards compatible code and coordinate the rollout accordingly.

My rule of thumb is no more than two distinct software versions can share a database at the same time. This effectively rules out database sharing between services. That way you push the problem to an API layer, which is better equipped to handle maintaining compatibility between many client versions.

View on HN

There is really nothing specific to API layer (I am assuming you mean REST API layer) in building backwards- and forwards-compatibility compared to databases. If anything, it is less powerful.

It is pretty easy to do with databases as well, you just need to adopt the right mindset.

For instance, if you think having an "api/vX" of an endpoint is acceptable, then it must also be to create a duplicate table/relation — you'll have exactly the same challenges in maintaining consistency between the two, though RDBMS offer quite a bit of tooling built-in.

The difference between a rest api (or gRPC or whatever) and a database schema is the degree to which clients of either are coupled to the data model. With a rest API, you have a degree of freedom to change the data model without breaking clients. Sure, you could implement that decoupling via views (for reads) and stored procedures (for writes) within a DBMS. This is generally clunky though, in my experience

API consumers are similarly tied to the exact API contract — what you need to do to maintain backwards compatibility is introduce a different view into it (which is why I bring up /api/vX as the common pattern).

There are even richer ways to change the DB model with triggers, for instance. Really, it's only clunky because we are not used to doing it (or do not know how), but there is no technical or conceptual limitation compared to API evolution.

Reply on news.ycombinator.com