Users may be unable to connect or experiencing degraded performance

Yeah, you definitely are, especially for larger companies. Just from one example: you can tell when a specific issue requires attention based on how many comments the thread has.

So let's say I wake up in the AM and there's a thread that says "how do I use the API for companyservice.example-api.com" and the thread has 50 comments.

Let's say it's a service I support. First, I know there's an issue because a customer required attention to begin with. This is then confirmed by the fact that the thread has 50 comments in it so there are probably documentation and usability issues with this service.

The company I work for and the services I am responsible for deals with internal customers and we use these two absurdly simple metrics to optimize support regularly.

When we first started with certain services that my team is responsible for, we used Slack metrics A LOT. As in, we had spreadsheets with this data and we'd go over them every week. Nowadays, our services are almost 100% self-service and we rarely, if ever, get pinged on Slack for those services because the documentation is optimized and the usability has been specifically designed so that our engineers don't get in the way of our customer's needs.

No threads is a feature IMO.

IMHO, at scale SQL will breakdown. Even with sharding like Slack is able to per organization. It's why we have great things like Cassandra and DynamoDB. They're designed to solve replication in an easier way than replicating RDBMS iff you know your data access patterns in advance and they're not ad-hoc (which SQL is great at). This is the case for Slack. The typical way to solve RDBMS bottlenecks is to put a queue and messaging system in front of them. This breaks down when your services have bugs (my guess at what's happening).

https://www.youtube.com/results?search_query=aws+rick

is pretty good on why some NoSQL approaches are a step forward (perhaps not MongoDB at scale if consistency is necessary https://jepsen.io/analyses). In particular though:

https://youtu.be/hwnNbLXN4vA?t=992

There could be other issues about why Slack is slow. But at Slack scale, you need to be extremely heightened in your database strategy or you should follow the industry and use Cassandra/DynamoDB's built in partition tolerance. Key value stores scale horizontally much easier. B-trees don't scale as easily horizontally past a certain point.

Essentially, good NoSQL DBs have abstracted scale for you (so you don't have to think about it as much). But you have to know the access patterns in advance (the types of queries and updates you'll be running for most use cases), since you need to design your table around these access patterns. RDBMS leaks scaling from the abstraction (you need to use message queues, etc.).

slow performance is the baseline for Slack...

> slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge

I'm pretty sure they have none of that, considering you can only edit your own messages. So what's likely happening is that two quick edits are reaching the server at the same time and overriding each other.