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

Slack’s migration to a cellular architecture

slack.engineering

Post reply on HN
Print view View original

261–265 of 265 posts

Re: Slack’s migration to a cellular architecture

#261

Post by gibb0n »

skybrian wrote: post #56
progbits wrote: post #15

Earlier quoted context omitted.

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.

That makes sense on its own, but doesn’t it mean that there are lots of network requests happening between silos all the time? It doesn’t seem very siloed. Or is this some lower-level service that “doesn’t count” somehow?

I think you are right, probably some service like kinesis of kafka that is keeping them in sync. that 'doesn't count'

Re: Slack’s migration to a cellular architecture

#262

Post by MockObject »

lopkeny12ko wrote: post #159
nostrebored wrote: post #119

Earlier quoted context omitted.

What do you mean? Slack is one of the most responsive and reliable tools I touch every day.

I hope this is satire. Slack is one of the slowest work tools I've ever used. Every interaction and click visibly lags. It's a sad state of the world that almost every application now is written in Javascript and deployed with Electron, and massive memory usage and slow UIs have become accepted as the norm. Try any IRC client and tell me, with a straight face, that Slack is just as responsive.

Very interesting. I have used Slack for work on a MacBook for years, and I have never once noticed any responsiveness issues or lags at all.

Re: Slack’s migration to a cellular architecture

#263

Post by asankama »

HumanOstrich wrote: post #256
asankama wrote: post #248

Earlier quoted context omitted.

In the CBA paper, a 'Cell' is an architecture construct you can use in the design stage and take through the development and then to the deployment. So, it addresses both application and deployment architecture. Each cell has a boundary, a cell gateway, and components inside the cell.

Thanks for the follow-up and I apologize for my snark. It appears my knowledge was out-of-date and I stand corrected. I'll need to brush up on the current docs and research.

No problem, it's my pleasure.

Re: Slack’s migration to a cellular architecture

#264

Post by robertlagrant »

skullone wrote: post #27
robertlagrant wrote: post #20

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.

I don't quite know what a PhD-grade architecture would look like, but this seems like a reasonabke one to me.

Re: Slack’s migration to a cellular architecture

#265

Post by eikenberry »

nostrebored wrote: post #120
t0mas88 wrote: post #115

Earlier quoted context omitted.

Since when is an "internal langue ecosystem" a good idea? Technology in a company like Slack exists to deliver useful features and good performance/stability to users faster than competitors can do it. For an app like theirs it doesn't sound like something that needs several disparate internal platforms that are slowing them down.

How is choosing the right language for a task/team slowing them down? For large scale, cross cutting initiatives you’ll have some pain. For feature velocity, you’ll see great results. Everything is a trade off.

Standardizing on a single language/toolset is a form of tech debt and has similar up/downsides. Comparable to, for example, how skipping testing will increase your velocity in the short run, but it will hurt it in the long run.
Post reply on HN