Microservice Re-architecture Part 2: Data Hurdle

Tags: microservices

This series of blog posts serves as a chronicle of a re-architecting of a monolithic web application to microservices.  Part 1 is here.  

I've been at Centerfield Media for a month now and I'm getting deep into our move to microservices. We are moving on up! There are quite a few hurdles. Let's discuss one.

Our current monolith is an MS SQL server back end. We have a few logical databases. Unfortunately they are not quite split along the domain boundaries we would like in our new microservices architecture. It's essentially one big logical DB and a few ancillary ones. That's OK. The big change is that we are moving to MySQL.


We are switching over to MySQL because it's...cheaper! We are also changing hosting providers. We're heading over to Amazon Web Services. These are fine choices in my book. The tough thing is that our current infrastructure takes full advantage of being one big database. That means lots of joins in stored procs. That's a lot to unwind.

Minimizing Change

We are moving to microservices yes, but not all at once! We are rolling out one lonely microservice first. Our old monolith needs to still function as we roll out our microservices. We can't refactor all the DB joins and roll out all the microservices and our core web app all at once. Too risky.  Ideally we want to have the legacy monolithic web app replace a few business layer calls with calls to a new microservice REST API. Minimal changes.

Data Flow

What we are planning to do at this point is synch the data from our new microservices MySQL backend to the old MSSQL DB. That way the old monolithic web app can function as is accept for the pieces that are being replaced by the first microservice roll out. I'm not crazy about it but that appears to be the best option at this point.

We will create a synchronization API on the old hosting location that can be called from the new microservice. This API will dump into queues and a worker process will pull from the queues and update the MSSQL database. The painful part is that each microservice rollout will have to include a rollout of this synch API.  Here's a picture.

There will be more to come in this great microservices adventure.  Here the first part.

No Comments

Add a Comment