Can someone review my microservice architecture ???

[pearl shoal]

I'm planning to rewrite my system with microservice architecture, Migrating from monolithic
I've spent a couple days reading about it and created this desgin. Pls add inputs to it

*Starting point is from left

1. first gateway will do authentication and authorisation
2. API gateway will redirect request to concerned microservice
3. Each microservice has it's own database, Trying to implement CQRS (not sure if this is correct)
   The database with green circle symbolises a read only (Query part)
   The red circle is a shared db where write operations happen

The read only db will achieve eventual consistency (planning to add a message broker/ queue for that)

4. The arrows between microservice define the dependecy, I'm planning to keep event-based as well as request -resp architecture among microservices communication, With TCP transporter (would appreciate some advice here too)

5. It's still unclear how to handle transactions, Although I'm trying my best to avoid transactions and joins, Read about SAGA methodology, thinking about handling it in API gateway

[safe pine]

First off, why microservices at all?

[pearl shoal]

So that i can scale each service independently,
There are only 4 services here, But I'm trying to functionally divide my system into microservices
For now please ignore the number of microservices

and their dependency with each other

keeping the services loosely coupled will help me add more features in future without architectural problems

[safe pine]

So that i can scale each service independently,

Why do you need to scale services independently? Do you already have thousands of concurrent users ready to use the system? Do you have 100s of developers working on the system already? Do you have a container orchestration environment built and ready to use?

I'm not trying to be facetious, just trying to understand this design decision, as it makes zero sense for anyone just starting a project.

[pearl shoal]

right now we dont, But it's expected in next 2 yrs to achieve these numbers
Although the developers count wont exceed 20
As it's a B2B product

sure, Feel free to ask.

plus we have more than 20-25 db tables

[safe pine]

Yeah, so build your app as a monolith first. Get it working. Nest done right will force you to think in a service oriented manner. Try to keep coupling between modules down as much as possible and still build your app like in the picture you gave above, the gray boxes being main modules. If you start to see the need to move to microservices, or you see a trajectory in growth where you know they'll be needed, you can start to tackle that problem then. You'll get to success a whole lot faster. Believe me. 🙂

[pearl shoal]

okay

[pearl shoal]

Thank you for the advice, Also is there a particular way/ best practises to manage dependency between modules

[safe pine]

If you do your domain management/ design well, your dependencies across modules should be where they need to be. Usually, if you run into strange problems with dependencies, it means you need to rethink the domain boundaries. Put a good bit of thought into the domain boundaries (as it seems you've done) and you'll be alright. 🙂

[pearl shoal]

Alright 👍

[pearl shoal]

@safe pine , I've started re-designing the monolith, I have functionally separated my modules, I have a question is it a followed practise where each module has more than one entity files and associated service and controller files for each of those entity ???
For e.g. A module of order-management might have tables orders, orderInvoices, salesOrders etc

so that in future i can directly take the module out and make it into microservice if needed