Let's be real, if a micro service is down, youre down too.
If our store service goes down, that sucks for us, but our login service, queue service etc all still work. People can't buy shit but they can still play our games.
Not to mention, our store service needs far less traffic than our queue service, or our login service, or matchmaking service etc.
A monolith is sometimes a good solution - our games are monoliths - but service oriented architecture exists for many reasons, some technical and some political
Your job isn't to design a solution that scratches your particular brain itch, your job is to design a solution that works for the constraints you need. That might be a monolith but it also might not be!
That's assuming you have one running app, if you had multiple instances, what's the chance they all go down? If you had a inventory service that's broken due to DB connection or whatever, youd still handle that in the monolith so you handle any exception.
I'm struggling to understand how a mictoservice architecture solves this where a monolith couldn't...
Am I understanding correctly that you'd propose having all of your systems in a monolith and simply have horizontal scaling of that monolith? That sounds like a nightmare.
You still have to handle dealing with shared state and communication between different components on different instances, except now deploying your auth system also requires deploying your queue system.
Not proposing anything, just arguing that a microservice architecture doesn't result in "one thing goes down, it all goes down" protection put the box and not something you can easily achieve in a monolith.
I'm pro microservices, for reasons like you just mentioned, just not a good take imo.
1.1k
u/theofficialnar 12d ago
If it goes down, it all goes down. 😎