Microservices - Database compatibility in between old and new versions

3
votes

I am trying to dive into Microservice architecture to start coding some of small pieces of logic for my company.

I know one of microservices concerns is about the database handling (each microservice must have its separated db schmema). So I am looking for pieces of advice or experiences about to move out from an old to new microservice version.

So lets say I have a REST API endpoint ms/v1/whatEver which is running today on prod. After a week we decide to go live with the next version of it. So that we create a ms/v2/whatEver which has some new columns and data types in the entities envolved in this service. Thus in order to not force all clients to migrate immediately we want to keep both versions up and running till users move in progressively to v2.

A couple of scenarios come up in to my mind if we have both version up and running (which actually is my main doubt and the reason of this post):

  1. Should they read/write in the same DB instance, hence v1 implementation must be adapted to match with the new schema structure of v2?

  2. Should they read/write in a separate DB instance. So in any manner both DBs have to be synchronised till the day we decide to turn off v1 to guarantee we do not miss any data (eventual consistency)? So my question here is how to accomplish that (throughout framework, queue messaging, or something..)

  3. Or, code forwarding every v1 request (inside of it) to v2 which is going to be the owner of the already migrated new schema (unique DB instance)?

I have been reading a couple of books like Migrating to Microservices Databases - Red Hat but they are written in concept terms but nothing specific with technologies or best things to do whit this. So that my post.

I really appreciate your opinions. Thanks

1
databaserestarchitecturemicroservices
AFAIK one of the concepts behind microservices is that each service has its own persistence so that what you are asking about never occurs. Microservices should not be divided using the classic presentation, business logic and persistence scheme. Overwise the DB MS would just be a REST API over the DB. – Philipp
I updated about the DB ownership per each MS. I am always talking about the same microservice, which is gonna be migrated to a new version of it. So my concern its about how to do that transition and keep the DB up to date till every user has moved in to the last version and turn off the previous one. – Lucas G
Having a db per microservice is not a must at all. It depends on your needs, you can have a shared DB, or a database-per-service. I'd rather have a signle AWS RDS with auto-scaling than having to handle multiple instances by myself. But again, it depends on each case. In this case I think the 3 different options are viable. I'd choose converting the old endpoint into a wrapper of the new one, this way you wouldn't have to maintain 2 different endpoints. So the new columns would be optional or should have a default value, all in the same db. – Willemoes

1 Answers

4
votes

This is one of the more complicated topics in services (not just microservices). I have done this two different ways.

1) Put in a backwards compatibility layer into the new service (thus allowing v2 to continue to service v1 client calls)

2) Keep the database backwards compatible, putting in intelligent defaults for new columns, only deleting columns once all relevant versions are removed.

Ultimately #1 has been the easiest to maintain over time, just because we rarely get everyone off the v1 services, leading to a messy db schema. An implementation where the api conversions happen as a chain, with each version converting to the next highest, until ultimately it reaches the current version.

I would avoid db-level synchronization if at all possible. It's rare that everyone gets off a given version, and once you get to a half-dozen of these sitting around you will be very sad.