which part

🐐

I feel with you. We have a large SharePoint Farm solution that is ~10 years old we work on

There is nothing great about this design btw.

@@arunsatyarth9097 No need a fancy architecture if the classic one get the job done and still easier to maintain.

@@lattelover7186 I didnt say the word "fancy". I just said there is nothing in particular here for Teams folks to look at and learn as OP suggests.

@@lattelover7186 "easier to maintain" on a 1M loc monolith php app... Do you even code?

Maybe due to the thundering hoard effect.

active-active can run into collisions when same data is updated in both parallely. Think your profile updated from phone and laptop simultaneously and one gets updated on Master1 and other on Master2. which one is the correct one? Time stamps could solve these collisions but manual intervention is needed sometimes there too. To solve this I think they have partitioned the queries (based on team id Keith says, but I think it would be more complex ) such that certain group goto Master 1 only and nver to master 2 , and vice-versa. Avoiding conflicts.

​ @Karan A Yeah it made no sense if the parition was just based on teamId because in that profile example the teamId's should be the same and so both requests go to the same master without introducing any conflict...

search "control and user plane separation" on google. it has many benefits. efficiency, security, isolation, capacity, scaling, easy managing, maintenance, failure-handling, etc.

I will not be surprised that it wasn't easy to support websockets/two way communication in LAMP at that time and this was easiest/fastest solution

Also likely to handle live websocket connections. You can only support 65k connections per server so scaling 80 full blown web apps just to handle dumb websocket connections may be overkill.

Their team was experienced with PHP. Time to market is key. Everything else is overrated for a start up. Now they can do whatever they want since they are successful.

GRPC or GDPR?

What's poor about it?

It's not a poor design. It's a design that allowed Slack to scale from a small start-up to one of the largest and best communication platforms. It's a very successful design. Good architecture and good design isn't one that contains all the hip buzzwords. Good designs are often very boring, and that's ok. That means an adult is in charge of the operations, not the hippies who sprinkled the latest immature fad and then leave the mess to someone else. The result is what matters, Slack is a very slick communication platform. Its architecture design may not contain sexy buzzwords, but it is what allows it to outshine all the other competitors who have buzzwords-driven design. That's not a "poor design".

...learning about the architecture of famous, successful companies making bags of money isn't applicable to system design interviews? Boring is *good*. I give system design interviews. I give massive points for boring, easy to operate, and easy to understand.

@@zbbentley and cheap total cost of ownership. ie cheap to build and maintain

Who do we have here? Someone who's too smart for our entire era. The title clearly says how Slack works or at least worked at the time this video was made. Now, since you found this video boring, assuming after coming here yourself, I wouldn't ever want to hire you adding already to the fact that you watched this video for preparing for a job interview? For system design? The whole idea of system design is that it may be different for every product, and you need to build one depending on what resources you have, what your timeline is and most importantly, what you really know for sure, say the fundamentals. If there was a standard and a fixed path, I'm sure this video wouldn't even exist. You wasted 20 minutes, but to everyone a favor and don't take any interviews. You wouldn't want to waste their time too.

Point is if u see this design u should have enuf knowledge to figure out the flaws and improve it on ur own

He didn't go in very deep, I'll give you that, but if you really found it boring, you'd not be trolling UKposts trying to win SD interviews. Let's chalk it up to the fact that you didn't hear some fancy words you might have expected, like Kafka, Cassandra, leaderless replication, and consistent hashing.