upvote

points

by grogers8 hours ago |
comments
upvoteby catlifeonmars6 hours ago|
next
[-]
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.

reply
upvoteby necovek4 hours ago|
parent|
[-]
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.

reply
upvoteby catlifeonmars53 minutes ago|
parent|
[-]
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
reply
upvoteby necovek4 hours ago|
prev|
[-]
I believe there are patterns that always work, but might not be optimal for all circumstances.

Eg. you could have a mirror table that you keep in sync with triggers without any constraints or foreign keys, do the migration on it, and then switch them around when ready.

reply