> At some point, you will have many teams. And one of them _will not_ be able to validate and accept some upgrade. Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team. Yes, this happens at slightly larger orgs. I've seen it many times.
The alternative of every service being on their own version of libraries and never updating is worse.
The most difficult part is managing the delivered / processed state and ordered delivery. Consistent ordering of receipt into a distributed buffer is a great challenge. Most stacks do that pretty well. But deciding when a message has been processed and when you can safely decide not to deliver it again it is especially challenging in a distributed environment.
That is sort of danced around a bit in this article where the author is talking about dropped messages, etc. It is tempting to say "use a stream server" but ultimately stream servers make head-of-line accounting the consumer's responsibility. That's usually solved with some kind of (not distributed) lock.
Yeah I mean I have to thank Facebook, because I was at Google in 2011.
Anyone remember when Google raised the entire company's salary, maybe 30K or 60K people at that point, something like 20-25% all at once? Eric Schmidt and Laszlo Block got on stage and told the whole company how great we are, so they want to keep us
It was low. I got a bump to 90k that year, then 130k when I jumped companies, which I thought was a mind boggling amount. Do entry level devs even get out of bed for $130k these days?
The alternative of every service being on their own version of libraries and never updating is worse.