51–60 of 265 posts
Earlier quoted context omitted.
> architecting for this is not really "advanced, FAANG-only accessible methodology" Sorry - where are you quoting this claim from?
My own words, but this is fairly trivial in the context of these massive companies with presumably PHDs working on their architecture.
So they run everything in AWS USE1? That doesn't seem very redundant, but then I guess if the whole of USE1 goes down Slack won't be the only service that will be affected.
[0] There are of course exceptions that come once every few years, but most instances people can think of in terms of widespread outages is one specific service going down in a region, creating a cascade of other dependencies. e.g. Lambda or Kinesis going down and impacting some other higher-level service, say, Translate.
Not being a dick here but is this not a fairly obvious flaw?
I mean why not keep a structured "message log" of all channels of all time ?
For every write the system updates the message log.
I am guessing and making assumptions I know.
Their siloing strategy, which I'll roughly refer as resolving a request from a single AZ, is a good way to keep operations and monitoring simple. A past team of mine managed services in a similar fashion. We had a couple (usually 2-4) single AZ clusters with a thin (Envoy) layer to balance traffic between clusters. We could detect incidents in a single cluster by comparing metrics across clusters. Mitigation was easy…
It sounds like you didn’t have persistent data, and were only offering compute? If there’s no need for a coherent master view accessible/writeable from all the clusters, there would be no reason to use multi-region cluster whatsoever.
How can such an architecture function with respect to user data? If the DB instance primary handling your shard is in AZ-1 and AZ-1 gets drained, how can your writes continue to be serviced?
Usually in distributed strongly consistent and durable systems, data is not considered committed until it has been persisted in multiple replicas. So if one goes down nothing is lost, but capacity and durability is degraded.
Or is this some lower-level service that “doesn’t count” somehow?
Earlier quoted context omitted.
> architecting for this is not really "advanced, FAANG-only accessible methodology" Sorry - where are you quoting this claim from?
My own words, but this is fairly trivial in the context of these massive companies with presumably PHDs working on their architecture.
Is Slack dead? unironically. Does it have a future? With Teams, etc. coming out, it seems most companies do not want to go the Slack route
If your goal is to monitor your staff and gather metrics on their communication - Teams outdoes Slack and is incomparable. If your goal is to have a platform that enables your employees to communicate with as little friction as possible, I have yet to see anything capable of replacing Slack. Teams especially, is something I loathe using every day. Everything about the UI and UX gets in the way of what I’m trying to d…