this post was submitted on 12 May 2024
189 points (90.9% liked)

Programmer Humor

32342 readers
1183 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 5 months ago (1 children)

Micro services are a lot easier to scale out since they behave independently from each other, you can have different levels of replication and concurrency based on the traffic that each part of your system receives.

Something that I think is pretty huge is that, done right, you end up with a bunch of smaller databases, meaning you can save a lot of money by having different levels of security and replication depending on how sensitive the data is.

This last part also helps with data residency issues, which is becoming a pretty big deal for the EU.

[–] [email protected] 4 points 5 months ago (1 children)

Something to consider is a monolith can have different entry points and a focused area of work. Like my web application monolith can also have email workers, and background job processers all with different container specs and scaling but share a code base.

And coming from a background where I work heavily with Postgres a bunch of smaller segregates databases sound like a nightmare data integerity wise. Although I'm sure it can be done cleanly there are big advantages with having all your tables in one database.

[–] [email protected] 2 points 5 months ago

I see, I'm definitely biased towards micro services after years of dealing with horribly made monoliths but I see what you mean.

At the end of the day I think both approaches have pros and cons.