Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a system highly available isn't just about adding redundancy

meesho.io

Post reply on HN
Print view View original

11–14 of 14 posts

Re: Making a system highly available isn't just about adding redundancy

#11

Post by citrin_ru »

8n4vidtmkvmk wrote: post #5
woleium wrote: post #2

Reading this, I can’t help but feel that things have got more complicated than perhaps they need to be. Microservices boundaries make most sense to me when they’re aligned with team boundaries, otherwise it just feels like making more work with little or no apparent gain.

Are you going to rebuild your micro service every time there's a reorg? It's nice as a SWE to own a specific service, but I think it leads to suboptimal tech stacks and adds latency.

It’s a bad reorg if it doesn’t take into account on which service(s) which team is working.

Also a team sized service is IMHO is a lower bound, not upper bound. I’ve seen a small team working on tens of micro-services and IMHO it is over engineering (but there are exceptions when small micro-services make sense).

Re: Making a system highly available isn't just about adding redundancy

#12

Post by 8n4vidtmkvmk »

citrin_ru wrote: post #11
8n4vidtmkvmk wrote: post #5

Earlier quoted context omitted.

Are you going to rebuild your micro service every time there's a reorg? It's nice as a SWE to own a specific service, but I think it leads to suboptimal tech stacks and adds latency.

It’s a bad reorg if it doesn’t take into account on which service(s) which team is working. Also a team sized service is IMHO is a lower bound, not upper bound. I’ve seen a small team working on tens of micro-services and IMHO it is over engineering (but there are exceptions when small micro-services make sense).

Ya, my team owns at least 4 services. It's a mess. One is deprecated, one calls the other 2 which just adds latency and redundant data fetches, and neither acts as proper 1st party API (there's always a debate about what service to call when another team wants to integrate with us), and the 4th is some pubsub thing which is invoked a completely different way, so that's one kinda OK. The most annoying part though is we still don't own the entire vertical. There's another 2 services downstream of us, and at least 1 upstream, so we're always at their mercy to accomplish anything.

Re: Making a system highly available isn't just about adding redundancy

#13

Post by 8n4vidtmkvmk »

KronisLV wrote: post #10
woleium wrote: post #9

Earlier quoted context omitted.

and what better way to spark joy on the new team than the opportunity to leave all the tech debt behind with a clean rewrite (in rust!) only half joking.

Regardless of the language or the trendy tech used, people seem to enjoy doing rewrites way more than working with old codebases, especially if their new solution doesn't need to be 1:1 with the old one and therefore they can justify no longer needing to work around certain edge cases. That longing can't really be helped, though. Honestly, as long as the second system effect doesn't ruin everything and you still make…

It always goes wrong. I've done it like 3 times now. Migrated from one language to another, and then it was taking too long so we rushed it (and also no one was proficient in the new language), so it became an utter mess. So now (3 years later) we're spending another year un-effing it (or trying to). Another one we switched data backends which yielded no performance benefits nor new features and was also rushed. And the 3rd was mostly fine (because it was small) except that it was deprecated like 6 months later because of another mandatory migration. Millions of dollars just wasted writing and rewriting things with little to no benefit.
Post reply on HN