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?
Slack’s migration to a cellular architecture
11–20 of 265 posts
Re: Slack’s migration to a cellular architecture
#12[flagged]
[deleted]
Re: Slack’s migration to a cellular architecture
#13Is 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
Clearly no. Legacy inertia will carry it pretty far, even if literally nobody new tries to sign up for it. Our team is still using Slack and has no plans to migrate away at the moment.
Re: Slack’s migration to a cellular architecture
#14Is Slack still written in Hack/PHP?
from the article: >Slack does not share a common codebase or even runtime; services in the user-facing request path are written in Hack, Go, Java, and C++.
Man what a mess. Meanwhile, everyone else can extend a library used by their common services in a common language trivially.
Re: Slack’s migration to a cellular architecture
#15How 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.
Re: Slack’s migration to a cellular architecture
#16Cellular architecture? They've just rediscovered the art of redundancy systems
Re: Slack’s migration to a cellular architecture
#17Is Slack still written in Hack/PHP?
Yes — see my recent article https://slack.engineering/hakana-taking-hack-seriously/
We use a few languages to serve client requests, but by far the biggest codebase is written in Hack, which runs inside an interpreter called HHVM that’s also used at Facebook.
Re: Slack’s migration to a cellular architecture
#18So they used a feature built into a load balancer to gracefully drain traffic from specific availability zones? Odd that a feature found in load balancers from the last 25 years is a blog post worthy thing.
That seems like a shallow dismissal. In a distributed system, making sure that sub requests are handled across distributed nodes within the local AZ, and correctly draining traffic from AZs with partial component service outages, is not as trivial as 'using a feature built in to a load balancer'.
It may be shallow, but architecting for this is not really "advanced, FAANG-only accessible methodology". I'm surprised their services have been as "reliable" as they have been considering such trivial stuff is just now being employed in their architecture.
Re: Slack’s migration to a cellular architecture
#19So they used a feature built into a load balancer to gracefully drain traffic from specific availability zones? Odd that a feature found in load balancers from the last 25 years is a blog post worthy thing.
Close but I don't think it's quite 25 years! I added graceful draining to Apache httpd's mod_proxy and mod_proxy_balancer either in 2003 or 2004, and at the time I'm nearly certain it was the first software load balancer to have the feature, and it wasn't available on the hardware load balancers of the time that I had access to ... though I later learned that at least BigIP load balancers had the feature. At the time…
Well played, HN.
Re: Slack’s migration to a cellular architecture
#20Earlier quoted context omitted.
That seems like a shallow dismissal. In a distributed system, making sure that sub requests are handled across distributed nodes within the local AZ, and correctly draining traffic from AZs with partial component service outages, is not as trivial as 'using a feature built in to a load balancer'.
It may be shallow, but architecting for this is not really "advanced, FAANG-only accessible methodology". I'm surprised their services have been as "reliable" as they have been considering such trivial stuff is just now being employed in their architecture.
> architecting for this is not really "advanced, FAANG-only accessible methodology"
Sorry - where are you quoting this claim from?