How to decouple one backend service associated with a database into two separate services?

Question

I have a big MySQL database, D_Big, with a bunch of data in it. I also have a service, S1, with APIs that read or write from this database. For example, one API might get something from the database. Another might write a row to the database. etc.

I also have a small, secondary database, D_Small, that S1 (and only S1) is reading and writing to. I want to leave the small secondary database alone, but I want to change the way data is accessed from the big MySQL Database, D_Big.

I want to make it so that the only way to access the big MySQL database is through API calls to a second service, S2, which also has access to the big database. When S1 want the data in D_big, it will have to call the APIs in S2 which will return the data in D_Big. Thus, I want to remove S1's direct dependency on D_Big.

What are some good ways to go about doing that? What are some tips/advice? The most straightforward way seems to be to replace every single API call in S1 that accesses D_Big directly with an API to a corresponding API in S2 that just performs the exact same database access that S1 would have performed directly. For example, imagine that we have these APIs in S1:

• API_1 returns columns [foo, bar, baz] from table1 in D_Big

• API_2 writes value foo to table2 in D_Big

• API_3 returns columns * from table3 in D_Big

I would just replace these with:

• API_1 in S1 calls corresponding API in S2 which returns columns [foo, bar, baz] from table1 in D_Big

• API_2 in S1 calls corresponding API in S2 which API_2 writes value foo to table2 in D_Big

• API_3 in S1 calls corresponding API in S2 which API_3 returns columns * from table3 in D_Big

But what about cases where the ideal mapping isn't one to one? Like when you should combine APIs (ex. one API in S1 calls two different APIs in S2 to get the data it needs or two different APIs in S1 call the same API in S2 but with different parameters)?

How do you make a good interface decoupling two services from what used to be a shared data source (D_Big)? Assume that both S1 and S2 use a Java/XML/Spring based system to transfer data over API calls.

Answer 1

If time allows, this seems like a perfect opportunity to move to CQRS. With CQRS you would have two APIs – one for writes and one for reads. You don't have the problem of multiple API calls because the API represents business ideas (ie use cases), not discrete entity access. Your front end should only submit one use case at a time, so there is only one API call. On the server side, your endpoint controller will make as many database reads or writes it needs to do in order to implement the business ideas.

CQRS is an excellent architectural pattern that will grow as large as necessary. I've had to omit a lot of important details in order to summarize it here. It would be worth the effort to learn about the pattern before you start your refactoring.

Answer 2

One thing is not clear to me. Is the data source being accessed by a single service (say S2) will make a decoupled architecture? Aren't the Services like S1 or S3..Sn are going to be coupled with S2 instead of the D1_Big, if the datasource itself is shared? To achieve true decoupling, the data sources should be decoupled among themselves which needs a careful data modelling -- microservices as a pattern helps having more bounded context which is good for decoupling.

Microservices or not, I would think instead of having a separate service S2 exposing data operations, let the data source be interacted by a separate codebase that produces a library/interface/jar which can be bundled along with the deploy-able that is produced for the interacting Service like S1 etc. Bundling of data jar within the S1 can be handled through a build process.

The Business Operation to Data Source mapping/interaction will be more performant than a service interaction in between. The layer can handle the data specific needs in CRUD (Simple READ/WRITE) or any Sophisticated ways (eg Views in RDBMS) it deems fit and expose data needed for business functionality and keep it client agnostic and still remains as a Scalable option.