3 ms·

Isn't this all a bit overcomplicated? The core of the product is text which concurrently might be only accessed by a few clients since it's enterprise software?

Isn't this all a bit overcomplicated? The core of the product is text which concurrently might be only accessed by a few clients since it's enterprise software? While overall it might be billions of requests I have worked on large systems in the past approaching that number on very few beefy servers with latency of around half a second average around the world when you don't need concurrent access. Edit: reading the article again I wonder how much of this is a self fulfilling loop caused by building on AWS using a bunch of services. The bot traffic might be significant. Although Telegram handles much more traffic than Slack and feels far faster when it comes to both bots and non bot communications. Not sure. Would be interesting to update the article on "why" any of this is needed in the first place. What was failing etc.

deleted 3y ago
[deleted]
Karrot_Kream 3y ago
Which part seems overcomplicated? This seems like a pretty basic setup for a web service with a (demanding-ish) SLA. > The core of the product is text which concurrently might be only accessed by a few clients since it's enterprise software? Some Slack communities have a few thousand users. Text messages also need to be ordered correctly, so it's not as simple as emitting text. > latency of around half a second average around the world when you don't need concurrent access I presume you mean without regional latency, in which case cool? Redis reads are a lot faster than 500 ms so this number is pretty much all just business logic which depends on the application.