221–225 of 225 posts
I watched this a while ago, and it did not fill me with confidence for the Slack backend at the time: https://youtu.be/WE9c9AZe-DY
This is more like how their infrastructure currently looks like I guess as it’s somewhat newer and follows up as an update to your video.
They still use MySQL though.
Earlier quoted context omitted.
> pessimistic rendering: waiting for the server response before updating the UI I hate the phrase "I'm a realist not a pessimist" as much as the next person, but isn't this actually "realistic rendering"?
To be wildly pedantic, pessimistic rendering would then be immediately showing an error, only to later clear the error away if the request is successful.
We are facing this error for the last few weeks, in case if a member drops off the call due to internet issues he/she can't join back until ~15 to 20 mins. We all are pissed off because of this horrible issue and planning to use something else for our stand-up call
I have intermittently faced each of these issues over the last hour across several European and a US Slack: * Messages are shown as sent (not grey), then, after several minutes, a "Try to send again" message appears. Or the message turns grey. Or both. * The webapp randomly reloads. Sometimes already typed messages are preserved, sometimes they disappear. ( I assume a reload happens when a new version is deployed wit…
I used enterprise slack ~4 years ago for a job and I remember having these issues every so often. ~2 years ago I used free gitter for a university project and I had the same issues a lot, and we had to switch -- funnily enough, we switched to discord and it was better than all of them.
Earlier quoted context omitted.
The core of Facebook, Twitter, YouTube, LinkedIn, all of Microsoft and lots more all run on MySQL and other similar RDBMS servers. It's a myth that you cannot scale MySQL.
Just doesn't seem like it makes sense for any type of long-term messaging/posts/comments store. I think you're mistaken about Twitter: "Manhattan(the backend for Tweets, Direct Messages, Twitter accounts, and more)" https://blog.twitter.com/engineering/en_us/topics/infrastruc... I'm not sure about the others (e.g., there's nothing recent for YouTube I could find.. likely they'd use Spanner though for things like comm…
The slack CTO's comment about choosing RDBMS because 'familiarity' is interesting. IMO it's a gamble. I've seen it happen with my company when being a latecomer to containerization.
When it came to picking a container management tool, it was a tossup between k8s, Nomad, or just saying to hell with and running those containers ourselves on EC2 instances. Having run our stack on bare metal for year = we were really pretty good at it. There was a surprising amount of automation that could be ported over.
Eventually we picked k8s, and coincidentally, our usage grew more in 6 months than it had in the last 2ish years. So all in all, the gamble paid off.
... but I like to think there's another world where we picked the 'its familiar option' and things still worked out. If our traffic hadn't grown the way it did, we would never have felt the pain of having to manually scale out our systems - or basically write an in-house version of Kubernetes.
So in that sense, I'd guess that maybe some teams have the bad habit of playing the same side of the coin everytime. It may be prudent to stay conservative when picking a Datastore, maybe it's would be smart to pick a risky technology for your app servers? (and vice-versa)