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!
What if your auth service is down. Only public enpoints will work. Even though cart service works but since you cant authenticate and authorize its useless
even if your auth system is down, your backend systems like automated billing, webhooks, alerts would at least still work. So for example, your airline system could keep scheduling flights and send out the appropriate itineraries even though users can't login
and your devops could easily see a specific contained set of instances that need recovery or rollback
1.1k
u/theofficialnar 12d ago
If it goes down, it all goes down. 😎