Skip to content
loading...
Discussion
markdown guide
 

I think ideally, a SOLID microservice architecture would imply that a service for model A doesn't care about the schema changes for model B, so migrations could live in the repo for the services they are for.

I could be wrong though, are you running into a specific problem?

 

Specifically, I'm using knexjs for migrations and I was unable to run migrations for files that were not present in the current service migration directory. What I mean is, KnexJS would look through its migrations folder and attempt to correlate previous migrations in the migrations table with the files present. If it doesn't find them, it throws an error. So I decided to move all the migrations to a separate service and do version control there.

 

Ah, I'm used to EntityFramework which stores it' "Last Migration" information in a table on the database, so I'm sure if that would be an issue.

Seems like a good enough reason to keep your migrations in their own repo to me.

There is also probably an argument that could be made for a monorepo for all your microservices.

 

Usually, in a microservices architecture, each service should have it's own DB.
I am not sure how your architecture looks like, maybe you can elaborate on this, but, as I said, each service should use it's own DB if necessary.

If you have a shared DB between multiple services, this is an anti-pattern, what you want to do here is: - to have only separate services responsible for specific entities/tables.

  • the migrations should only run from one specific service.

here's some resources:
microservices.io/patterns/data/dat...

Also here's how we do it in my company:
runtastic.com/blog/en/entity-datab...

 

Actually, you are incorrect here. A shared DB is not an anti pattern. But you definitely want to have separate tables.

From the article on microservices.io that comes after the article you posted:
microservices.io/patterns/data/sha...

 

The Grubhub tech blog put up an article about how they did exactly this when they moved both the legacy Seamless and Grubhub data to a new SOA platform while all three were in use: bytes.grubhub.com/a-migration-stor....

The short of it is, yes, you should have a separate service handle the migration, but also consider giving that service direct database access and ensure that all responses are idempotent in case communication fails in the middle of a migration.

Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

Adekoyejo Akinhanmi profile image