Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Users may be unable to connect or experiencing degraded performance

status.slack.com

Post reply on HN
Print view View original

141–150 of 225 posts

Re: Users may be unable to connect or experiencing degraded performance

#141

Post by flavmartins »

JMTQp8lwXL wrote: post #136
jacquesc wrote: post #13

This backend outage reveals how horrible the Slack UI is implemented. You post a message.... you think it got sent. Then 1min later, it tells you it was not.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

It's especially bad if you're on mobile and in an area that might have spotty reception.

You post a message, it looks good, you move on.

Then later on you come back to it and it was never sent.

Re: Users may be unable to connect or experiencing degraded performance

#142

Post by outworlder »

seibelj wrote: post #11

Slack is unusable, but it did get me to restart Docker which had ballooned to 16 GB memory and a bazillion processes. Modern software development is something else

> but it did get me to restart Docker which had ballooned to 16 GB memory and a bazillion processes.

Hey, so in 2020 we have unlimited sandboxed environments that do not require virtualization and can be spun up, destroyed very quickly, and their construction is fully automated. And it's somehow a bad thing?

Get off my lawn! When Docker arrived it was a godsend, given that we were trying to do similar things directly with LXC.

(I'm fully expecting someone to chime in saying, 'you had LXC? All we had was ones and zeros, and we had ran out of zeros')

Re: Users may be unable to connect or experiencing degraded performance

#143

Post by n4r9 »

JMTQp8lwXL wrote: post #136
jacquesc wrote: post #13

This backend outage reveals how horrible the Slack UI is implemented. You post a message.... you think it got sent. Then 1min later, it tells you it was not.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

> 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"?

Re: Users may be unable to connect or experiencing degraded performance

#144

Post by breatheoften »

paxys wrote: post #139
breatheoften wrote: post #91

Earlier quoted context omitted.

I frequently send - edit send - edit the same message in an effort to reduce the number of typos. Recently i've realized that this actually introduces more typos -- where a large number of phrases are duplicated or corrected typos reapplied. There's something wrong with slacks operational transform or CRDT implementation or whatever they use to get edited messages to converge

> 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.

I could be wrong but i'm relatively sure that I reach message states that do not directly correspond to anything i typed into the editor -- which i wouldn't expect if the edited state was always sent in full rather than as a delta on a previous message state.

I suppose it's possible that the corruption happens on the client side tho --

1. initiate edit action and get editable view of snapshot of text

2. server acks some previous edit request causing some client state related to the message to update and promote a previous edit in some way

3. hit save after finishing editing -- and some delta operation on the client side updates a different message state than the one i initiated edit action from ...

Re: Users may be unable to connect or experiencing degraded performance

#145

Post by paxys »

jsmith12673 wrote: post #59
TheUndead96 wrote: post #14

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

Could someone comment on why exactly this a poor design for their backend? Genuinely curious, I don't have any real world context on systems like this.

It's a pretty normal, solid design.

Re: Users may be unable to connect or experiencing degraded performance

#146

Post by dimtion »

flavmartins wrote: post #141
JMTQp8lwXL wrote: post #136

Earlier quoted context omitted.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

It's especially bad if you're on mobile and in an area that might have spotty reception. You post a message, it looks good, you move on. Then later on you come back to it and it was never sent.

The new Slack on mobile is absolutely unusable. There are no way to know if the interface is up to date, when was the last update or to force an update.

The only way I found to know that your message has been received is to have an ack from your interlocutor.

Re: Users may be unable to connect or experiencing degraded performance

#147

Post by paxys »

tmsh wrote: post #135
jsmith12673 wrote: post #59

Earlier quoted context omitted.

Could someone comment on why exactly this a poor design for their backend? Genuinely curious, I don't have any real world context on systems like this.

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 an…

Is the whole "NoSQL is better than SQL!" thing still going on?

Re: Users may be unable to connect or experiencing degraded performance

#148

Post by tmsh »

paxys wrote: post #147
tmsh wrote: post #135

Earlier quoted context omitted.

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 an…

Is the whole "NoSQL is better than SQL!" thing still going on?

It’s proven itself for scaling. Mostly startups don’t see the issues with SQL and don’t need to worry about it. At planet/top-Alexa-ranked-website scale though, you either use Spanner at Google, or use Cassandra at Apple, DynamoDB at Amazon, Cassandra at Instagram, parts of Facebook, Netflix, Manhattan at Twitter etc.

You keep using MySQL at Github and Slack if you want periodic downtime/degradation in service tho.

Re: Users may be unable to connect or experiencing degraded performance

#149

Post by swaraj »

rexreed wrote: post #60

Is Discord a viable alternative to Slack? If not, why not?

we have fallen back to discord for work today. Obviously the terms/security controls are not a great permanent solution, but it's a great fallback for real-time chat across all devices

Re: Users may be unable to connect or experiencing degraded performance

#150

Post by benmller313 »

n4r9 wrote: post #143
JMTQp8lwXL wrote: post #136

Earlier quoted context omitted.

The concept is called 'optimistic updating' and the intent is to make the UI 'feel faster' by assuming a positive response from the back-end, and only reverting when things go awry. Given the vast majority of messaging attempts will complete successfully, it's easy to see why the interaction pattern is used. The converse is pessimistic rendering: waiting for the server response before updating the UI (and possibly sh…

> 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.
Post reply on HN