[HN Gopher] Real-Time Messaging
___________________________________________________________________
Real-Time Messaging
Author : fagnerbrack
Score : 56 points
Date : 2023-06-23 20:04 UTC (2 hours ago)
(HTM) web link (slack.engineering)
(TXT) w3m dump (slack.engineering)
| rmf11048 wrote:
| [dead]
| matlin wrote:
| Kind of funny timing because I've noticed my messages in Slack
| have been quite a bit more delayed than usual for the last few
| months, especially when moving between devices. Maybe they need
| more "channel servers"
| TeMPOraL wrote:
| They're preparing you to the real-time messaging experience
| when you're working remote from Mars.
| cj wrote:
| Noticed this today, too. I turned on a computer I haven't
| logged in to in 2 months, and clicking a channel took at least
| 5 seconds to open/load. And then it worked normally after that.
| nkozyra wrote:
| I've noticed a big performance drop in the last few weeks as
| well.
|
| Everything has gotten more sluggish.
| stavros wrote:
| Same here, all channels took 5 seconds to load. I've used
| Slack on that computer recently though.
| pipe_connector wrote:
| Lots of people being negative about this, but if you've ever
| implemented anything that works in near-real-time at wide scale,
| most of this design makes sense and it works great.
|
| One thing interested me: Why the difference in pathing between
| events and messages? I think the event flow makes sense, but why
| not have messages also go through your gateway server instead of
| through webapp? Surely there is needless latency there when you
| already have an active websocket open to gateway? I thought
| perhaps it was because your gateway was for egress-only, but then
| the events section made it clear you also handle ingress there.
| paxys wrote:
| Slack messages did in fact post through websocket at one point
| (and still do in some cases like when sent by chatbots). Why
| they switched it to HTTP-only I can't say.
| tekkk wrote:
| Interesting architecture. Asynchronous message passing at scale
| becomes quite a PITA very quickly. Wonder how scalable the code
| base really is. Probably Java isn't that bad of a choice
| considering the tooling although it's not my personal favourite.
|
| Seems quite the ideal use-case for Elixir/Erlang but since
| haven't used it myself, don't know would it be that much better.
| Especially training/developer pool -wise.
|
| And Vitess/MySQL for persistence? No Cassandra or something
| similar?
| jw1224 wrote:
| This seems complex, and not necessarily in a good way
| bombolo wrote:
| > They replace unhealthy CSs very quickly and efficiently
|
| Maybe fixing the bugs so that they don't mysteriously get ill
| would be a thing to pursue?
| AlotOfReading wrote:
| I'm sure they have whole teams dedicated to that, but even
| perfect software would still need these sorts of health checks
| at the scale slack operates. Sometimes you just have random
| failures in hardware or the OS, or you need to migrate software
| around the datacenter without bringing down the service. This
| is a generic way to do around all of that.
| paxys wrote:
| Silly engineers, implementing things like failovers and
| redundancy. Why can't they just ensure that their servers never
| crash?
| 0xCAP wrote:
| Who suggested they're not doing that already?
| mabbo wrote:
| A dumb pet peeve I have is the use of the term "real time".
|
| What on earth do you even mean by that?
|
| Talk to a controls engineer about real time operating systems and
| PLC programming, and you get a very solid definition. Talk to a
| software developer and it means something like "as fast as we
| can, without any purposeful delays or buffers".
|
| Maybe I'm just a pedant, but the entire article has graphs with
| no numbers, no defined service level objectives, and vaguely
| mentions 500ms at the end.
|
| What is real time?
| Wingy wrote:
| I'd say anything that users perceive as instantaneous.
| smallnix wrote:
| And even that depends very much on the type of interaction.
| E.g. Tactile Feedback vs visual.
| pc86 wrote:
| What kind of tactile feedback is there in Slack?
| paxys wrote:
| > Talk to a software developer and it means something like "as
| fast as we can, without any purposeful delays or buffers"
|
| No, "real time" in a software context means having a persistent
| TCP/UDP connection open between a client and a server (or two
| clients in case of WebRTC etc.) to exchange data, skipping over
| traditional paradigms like having to establish new HTTP
| connections or being blocked on database fetches. This is a
| well-established definition, and has nothing to do with a
| specific number for latency or any other such metric.
| eikenberry wrote:
| Why would an asynchronous messaging platform worry about real-
| time messaging? It seems rather counter to what the platform is
| meant for.
| nomel wrote:
| > It seems rather counter to what the platform is meant for.
|
| Well that's just silly, if you've ever used used slack. It's
| corporate chat rooms, with real-time chat being a fundamental
| feature of it.
|
| > counter to what the platform is meant for.
|
| The platform is meant for communication. Async communication is
| one (probably smallish, at least in my experience) slice of
| that.
| pc86 wrote:
| No you don't understand, the GP uses Slack asynchronously so
| if you _don 't_ use Slack asynchronously you're doing it
| wrong.
___________________________________________________________________
(page generated 2023-06-23 23:00 UTC)