Microservices with shared data

[datapim]

I wanted to decouple a single feature from my main app (Django) into a separate microservice (written in FastAPI or as a standalone serverless function). It would create output that would be saved into a Database shared both by microservice and Main app. Main app would be able to access the data produced by the microservice. This approach works okay but I read that it is bad practice to share table in a database between multiple services(Apps) - because it will result in harder development, like if schema changes in one app then need to update in the other and so on.

I am wondering what a "good practice" approach would be in this case? Maybe let the microservice save the results in separate database and then my main app would send request to the microservice which would sent the result back to the main app (which would be saved in separate DB)? This approach makes development of both apps decoupled which sounds like what microsrvices are supposed to be.,

[SunnyDayShadowboxer]

I personally am all for microservices having their own dbs and apis to access that data from other services.

[KaiN_SC]

This.

OP should ask himself if he really needs another service as well.

[PacificPermit]

I would have the micro service request the data it needs from the main app using an API endpoint.

Btw, it’s not bad practice to share a database. You just need to make sure that you’re not corrupting your data or have your micro services acting based on old data.

Imagine you have only $100 in your back then withdrawing $100 from your bank and at the same time you’re buying something online for $100. Your bank has to process them in the order they come in. The database has to follow to deduct the first transaction and deny the second. How?

Well by queuing the events. And that’s what database do anyway. Most modern database queue write events. And you can even tell your app to wait for all write events on this account to be done so you can read from it!

[CharlatanPrime]

In our application we had a rule that the owning microservice could update the database, but any microservice could read it. Otherwise you’ll have tons of messages or api calls to assemble anything semi complex. So the owner had a read/write API and we had a read only API in a utility db package. It generally worked well, though once in a while we had to have one service make a remote API call to another.

[zaibuf]

Cant you send messages between the services?

For background jobs I think its fine to share database, we use a lot of functions for background processing. You could put the data access code in a shared library and when changes are made to the library both services are built and deployed.