Microservices that needs to change row in shared DB

Question

I have an application that can be reduced/simplify to this flow:

1. user sends request to app A
2. app A inserts info about the request and user into DB ( marked as "B in progress" and "C in progress")
3. app A pushes the data into queue and returns to user
4. app B retrieves data from queue and process it
5. app B finishes processing the data and marks record in DB as "B done"
6. app C retrieves data from queue and process it
7. app C finishes processing the data and marks record in DB as "C done"

In other words, user sends request to app, app saves the record to the database and send it to queue, app B and C takes request from queue and process it ( each app does different thing but requires data from request ) and when they are done i want to mark the request in db as done for both APP.

This can be achieved, if all apps share DB. However sharing the DB like this between microservices is considered anti-pattern.

What are some design patterns to solve this? Am i really left with only option - make app A expose rest API and call the endpoint from app B and C to update the row in DB?

Thanks for help!

• JimmyJames: It seems like you are on the right track but it's worth mentioning that microservices don't require every endpoint or 'service' to be separated. It's completely valid to have multiple services in the same application in a microservices design.
• Steve: "sharing the DB like this between microservices is considered anti-pattern" - the problem with microservices is that most useful computer applications involve a careful integration of operations upon shared data. A modern saying could be that "every problem in computing can be solved by another separate microservice - except the problem of microservices being separate".
• user1450877: Neither Service A, B or C seems to be using the data in the database for anything. What is it being used for ?

Answer 1

Am i really left with only option - make app A expose rest API and call the endpoint from app B and C to update the row in DB?

If you're doing microservices properly, yes. Don't forget to version the REST API. Either that or consider A, B, C to be part of the same service.

What do I mean by "properly"? Well, the motivation of splitting an architecture into (micro)services is that they can be maintained independently, by separate teams, on separate release cycles.

What happens when A wants to change the schema of the database? In a true microservice, you can just do that, because the database is not exposed outside the service. If you have to coordinate the schema change with B and C, they're not separate services.

• Johnyb: the request data does have some UUID like property that can be used for identification. So the service B and C do not need to know the schema of DB if they know the request data. However, is this ping pong style good pattern? This solution seems intuitive, but still seems like there must be elegant solution
• pjc50: The other "elegant" solution is to admit that they're all part of the same service. It depends on how many millions of lines of code these services are?
• Johnyb: Service B has around 15k lines of code, and service C will be newly created. Service A is basicly back end for GUI wrapper around this whole process. Old way used some scripts to send data directly to service B (and then some manual processing i think). New way will be website that offers nice UI and makes the whole process of sending data much easier + some utilities. Service C is new additional functionality to this 'pipeline' .
• Stack Exchange Broke The Law: @Johnyb It's microservice pattern. If you don't think it's good then maybe don't use microservices and don't pretend they are microservices.
• Johnyb: @user253751 i am not pretending they are, they seem to me like good adept to be microservices, and as i am not experienced that much in this concept, thats why i am asking here :)

Answer 2

I'd simply use the request-response pattern here:

• a saves job to database and sends the jobs to the queue
• b and c process the request and send their result or "finished" message back to a
• a updates the database

This way, b and c don't have to do anything with the database and you achieve a somewhat cleaner decoupling.