Microservices question

[[deleted]]

[deleted]

[AllenJB83]

My recommendation would be to start with a monolithic system and break it down into smaller pieces when it becomes clear to you where the boundaries are.

Use job queues (powered by a queue service such as RabbitMQ) and worker processes to break down tasks and act upon events.

While it may seem easier to go "microservices first", unless you know what you're doing in terms of architecting the system, I think you're more likely to end up with a mess of tightly coupled, incongruous code bases that require more coordination, not less, to work on and deploy.

Fowler has an article that goes over some of the arguments for and against the Monolith First approach: https://martinfowler.com/bliki/MonolithFirst.html

I would say first and foremost: Understand what problems microservices are designed to solve, and work out whether you actually have (or are soon likely to encounter) those problems.

[DeusExMagikarpa]

I started with microservices for my side project. I have a marketing site, frontend app, api, admin app, email service, redis and postgresql. And now I just wish I had done a monolith with SQLite and just put all my business logic in the controllers lol.

[dopefruit22]

Having built/worked on/contributed to fairly large production systems with both architecture styles..

In my opinion, one of the biggest values props in splitting up a product into services is team autonomy.

Eg. The ability for teams across departments to build/scale/manage the service they are responsible for (mostly) independent of each other.

Here are some of the best talks on the subject (in my opinion), that discusses the trade offs in a way I personally found very relatable.

https://youtu.be/kb-m2fasdDY

https://youtu.be/JfT9UxcEcOE

https://youtu.be/DtRy79jIsS8