5 ms·

> I don't want to be that person who says "mrahhh a new CS graduate could have built Teams in 2002 and it would have been faster!" But I'm also like, whatever i

by muglug 4y ago

> I don't want to be that person who says "mrahhh a new CS graduate could have built Teams in 2002 and it would have been faster!" But I'm also like, whatever is stopping it from being faster, I can't imagine what that is from where I'm sitting! > it's very simple data. Mainly a series of messages, displayed in chronological order. That's one of the most straightforward possible things to optimize. When a company grows and add features that customers need, the data model has to grow with it. Queries necessarily become more complex. I used to work at a big video sharing site. I wasn't there in the beginning, but I imagine the initial profile pages had code like SELECT * FROM user_videos WHERE user_id = ? Then some users said "hey, we want some of our videos to be private". So then the simple query became SELECT * FROM user_videos WHERE user_id = ? AND privacy = ? Then they said "ok, but I want people who are mutual friends to be able to see some just-for-friends videos". And then the query suddenly became much more convoluted. We started loading all of a users' videos in memory, then in-memory filtering, returning only the videos the viewer had access to (slow for users with thousands of videos). Then some users came along with 30,000 videos and we had to abandon the in-memory filtering because we were getting OOMs, so we developed a hybrid system that could run queries either in-memory or in the DB depending on volume. This is a trivial example (there are much more painful examples of data model bloat) but it illustrates the point: if you think it should be easy, you probably have an innacurate mental model of what needs to happen behind the scenes.

fxtentacle 4y ago
We're talking about Teams here, the modern UI for what used to be IRC chat. 10k users on a single server used to be a solved problem for this type of application.
- bigtunacan 4y ago
  Yes, that's the real elephant in the room. Slack and Teams both packaged up IRC into something that looks nicer, but runs 1000x slower and now sell enterprise licenses for this garbage.
- muglug 4y ago
  > We're talking about Teams here, the modern UI for what used to be IRC chat. That's like saying that Chrome is a modern UI for what used to be Lynx. Those tools offer very different features, even if they share a rudimentary set of behaviours.
- roflyear 4y ago
  That's not really fair to teams and I hate it too
droopyEyelids 4y ago
Yes thats what the person you are replying to is asking about these chat apps. What is adding the complexity to the chat apps.
brundolf 4y ago
Maybe. I have more experience on the UI side, so my intuition may be off here, but I still have trouble believing that these kinds of basic slicing-and-dicing-records problems aren't solved already. Especially when we're talking separate workspaces per-org, which could each get their own DB or shard; you can't hold all those messages in client-side memory at once, but surely at the DB level it's still much less data to process than what eg. Twitter deals with. Databases are fast, and this seems like a very vanilla database-shaped problem
- muglug 4y ago
  Twitter is very read-heavy. Think about the average timeline — Tweets don't change (they recently introduced "editing", but it's not an in-place edit). That means many things can be heavily cached, and most people on Twitter aren't writing Tweets, so the write volume is relatively low compared to the read volume. Now think about the average chat app like Slack or Teams. Those have a very different read-write ratio. Some things can be cached for long periods of time, but many other entities become invalidated quickly, and are subject to intricate permissions policies. As for sharding, Slack uses Vitess: https://slack.engineering/scaling-datastores-at-slack-with-vitess/ https://slack.engineering/scaling-datastores-at-slack-with-v...
  - brundolf 4y ago
    I guess, although: > most people on Twitter aren't writing Tweets I don't know how true this is. Most people in my corner of twitter tweet several times a day, some of them have rapid-fire conversations in the replies. And that cache-busts (or at least appends to) a whole lot of people's feeds, just like it would people's chat history (while in both cases, almost all writes are appends) But idk, I'll stop speculating here because I'm not basing it on much
    - fmajid 4y ago
      Twitter is the first implementation of write-only memory.
deathanatos 4y ago
While … sure, that's all true enough, I still routinely watch the UI load. E.g., clicking the "emoji" window in Slack. I'll permit the custom emojis in the LRU emoji list to delay, but even the stock Unicode "text" emoji take palpable time to "load".

by muglug 4y ago

fxtentacle 4y ago

We're talking about Teams here, the modern UI for what used to be IRC chat. 10k users on a single server used to be a solved problem for this type of application.

bigtunacan 4y ago
Yes, that's the real elephant in the room. Slack and Teams both packaged up IRC into something that looks nicer, but runs 1000x slower and now sell enterprise licenses for this garbage.
muglug 4y ago
> We're talking about Teams here, the modern UI for what used to be IRC chat. That's like saying that Chrome is a modern UI for what used to be Lynx. Those tools offer very different features, even if they share a rudimentary set of behaviours.
roflyear 4y ago
That's not really fair to teams and I hate it too

droopyEyelids 4y ago

Yes thats what the person you are replying to is asking about these chat apps. What is adding the complexity to the chat apps.

brundolf 4y ago

Maybe. I have more experience on the UI side, so my intuition may be off here, but I still have trouble believing that these kinds of basic slicing-and-dicing-records problems aren't solved already. Especially when we're talking separate workspaces per-org, which could each get their own DB or shard; you can't hold all those messages in client-side memory at once, but surely at the DB level it's still much less data to process than what eg. Twitter deals with. Databases are fast, and this seems like a very vanilla database-shaped problem

muglug 4y ago
Twitter is very read-heavy. Think about the average timeline — Tweets don't change (they recently introduced "editing", but it's not an in-place edit). That means many things can be heavily cached, and most people on Twitter aren't writing Tweets, so the write volume is relatively low compared to the read volume. Now think about the average chat app like Slack or Teams. Those have a very different read-write ratio. Some things can be cached for long periods of time, but many other entities become invalidated quickly, and are subject to intricate permissions policies. As for sharding, Slack uses Vitess: https://slack.engineering/scaling-datastores-at-slack-with-vitess/ https://slack.engineering/scaling-datastores-at-slack-with-v...
- brundolf 4y ago
  I guess, although: > most people on Twitter aren't writing Tweets I don't know how true this is. Most people in my corner of twitter tweet several times a day, some of them have rapid-fire conversations in the replies. And that cache-busts (or at least appends to) a whole lot of people's feeds, just like it would people's chat history (while in both cases, almost all writes are appends) But idk, I'll stop speculating here because I'm not basing it on much
  - fmajid 4y ago
    Twitter is the first implementation of write-only memory.

deathanatos 4y ago

While … sure, that's all true enough, I still routinely watch the UI load. E.g., clicking the "emoji" window in Slack. I'll permit the custom emojis in the LRU emoji list to delay, but even the stock Unicode "text" emoji take palpable time to "load".