Leveraging the Process Context In Modular Monolith

I’m currently on the research if my current monolith architecture
can be improved by moving to micro-services.

From what I saw, there are a lot of good things about micro-services
but there is a low of caveats and pit-falls that might complex
the whole system (transactions, data-query, data-sync and duplication, fault tolerance, error handling, etc)

Seems that there is the middle ground of going into a “Modular Monolith” (1,2,3) where the system is designed vertically into a loosely coupled modules that interact using APIs.

The question is how the fact that these modules operate against the same database and sit in the same process space can be leveraged to ease the complexity, i.e:

  1. Can the modules declare “Transaction Context” in their API that will allow an ACID transaction when there is a cross-modules business logic operation? (in contrary to micro-service where it’s not achievable by design)
  2. Declaring database Views in special modules that will allow joining data on the database level and not on the application level.

If these cannot be leveraged – what’s the real difference between modular-monolith & micro-services (besides the independent scaling and deployment)

Go to Source
Author: sborpo