Linguagem
É a linguagem do Webapp, o monólito que hospeda todas as APIs que os apps do Slack chamam.
Por quê: O verificador de tipos pega os erros enquanto a pessoa digita, o que deixa as refatorações mais seguras.
TypeScriptslack.engineering
Tipa o código JavaScript do app de desktop.
Por quê: Precisavam de garantia de que as partes se encaixavam, coisa que os comentários em JSDoc não davam.
Biblioteca de interface
Reactslack.engineering
Monta todos os componentes de interface do app de desktop.
Por quê: Atualiza a interface sozinho quando os dados mudam, acabando com os erros dos templates atualizados na mão.
Framework full-stack
Electronslack.engineering
Empacota o app de desktop, agora com todos os workspaces num processo só.
Hospedagem
Hospeda a infraestrutura central em várias zonas de disponibilidade da us-east-1, cada uma tratada como uma célula.
Kubernetesslack.engineering
Roda os serviços pelo Bedrock, a plataforma interna de computação do Slack.
Por quê: O Bedrock quer facilitar subir serviços prontos para produção e esconde a complexidade da infraestrutura.
Envoyslack.engineering
Balanceia o tráfego na borda, no lugar do HAProxy, e esvazia as zonas com problema.
Banco de dados
MySQLslack.engineering
Guarda os dados do Slack, de mensagens e canais às informações do diretório de apps.
Vitessslack.engineering
Fatia o MySQL e atende quase todo o tráfego de banco do Slack.
Por quê: Precisavam de um fatiamento flexível para os recursos novos, além de failover e backups prontos.
Busca de dados
Apache Kafkaslack.engineering
Segura os jobs de forma durável na frente da fila do Redis.
Por quê: Só com o Redis não dava para garantir a gravação quando a fila acumulava.
Redisslack.engineering
Roda a fila de jobs de envio de mensagens, notificações push e cobrança.
Reduxslack.engineering
Mantém uma store por workspace com os dados, o status da conexão e o WebSocket.
Framework de servidor
Roda o backend em Hack.
Por quê: Em 2016, rodava o código PHP deles mais rápido.
Move o núcleo de tempo real: servidores de canais, gateway, administração e presença.
Roda o Kafkagate e o JQRelay, que levam os jobs entre o Kafka e o Redis.
Modelo de IA
Amazon Bedrockslack.engineering
Serve os LLMs da Slack AI desde meados de 2024.
Por quê: Os modelos novos chegavam lá primeiro, com acesso imediato em vez de ficar correndo atrás no SageMaker.
Vertex AIslack.engineering
Coloca o Google Cloud como segunda plataforma de LLMs da Slack AI.
Por quê: Traz redundância e um catálogo maior de modelos.
O Slack estreou em 2014 em PHP 5. Em 2016 foi para o HHVM porque ele rodava o código PHP mais rápido, e depois adotou o Hack, que acrescenta tipagem estática. O modo parcial do Hack permitiu tipar arquivo por arquivo, deixando as refatorações mais seguras sem reescrever tudo de uma vez.
Quando o HHVM 4.0 deixou de aceitar PHP, o Slack tirou todo o PHP que restava. O preço foi perder acesso à maior parte dos pacotes do ecossistema PHP.
Fontes:slack.engineering
Desde o começo o Slack guardou os dados em MySQL, fatiado por workspace, com o monólito decidindo para onde ia cada consulta. Com mais clientes e recursos, esse modelo gerou pontos de sobrecarga, quedas de shards inteiros e um modelo de dados engessado.
Em 2017 o Slack começou a migrar para o Vitess, que coloca fatiamento flexível, failover automático e backups em cima do MySQL. No fim de 2020 o Vitess já atendia 99% do tráfego de MySQL do Slack, cerca de 2,3 milhões de consultas por segundo no pico.
Fontes:slack.engineering
O app de desktop do Slack rodava cada workspace logado num processo próprio do Electron, feito com jQuery da época de 2012 e templates HTML atualizados na mão. A memória crescia a cada workspace, e os workspaces grandes baixavam dados demais logo de cara.
A reescrita de 2019 exigiu que todo componente de interface fosse feito em React, deu a cada workspace sua própria store do Redux dentro de um único processo do Electron e reduziu bastante o uso de memória. O código do desktop já tinha ido para TypeScript em 2017, para garantir que as várias partes se encaixassem.
A fila de jobs do Slack rodava no Redis até que uma lentidão no banco encheu a memória do Redis e derrubou o serviço. Em 2017 colocaram o Kafka na frente do Redis como um buffer durável, com dois serviços pequenos em Go levando os jobs de um lado para o outro.
Depois de um incidente em 2021 em que uma zona de disponibilidade da AWS degradou, o Slack passou cerca de um ano e meio transformando os serviços críticos em células, uma por zona, para tirar o tráfego de uma zona ruim sem erro para o usuário. Os serviços rodam no Bedrock, uma plataforma interna de Kubernetes que reduz a configuração de cada serviço de centenas de linhas para dezenas.
Fontes:slack.engineering slack.engineering slack.engineering
A Slack AI estreou em 2023 no SageMaker da AWS, escolhido pela segurança, pela conformidade com o FedRAMP e pelo controle dos modelos, com os LLMs rodando numa VPC de custódia para o fornecedor do modelo nunca ver os dados dos clientes.
Os modelos novos sempre chegavam antes ao Amazon Bedrock, então em meados de 2024 o Slack foi para lá para ter acesso imediato. No início de 2026 entrou também o Vertex AI do Google Cloud, por redundância e por um catálogo maior de modelos.
Achado na página inicial com as regras abertas do Wappalyzer (HTML, scripts e cabeçalhos). Mostra o que roda no navegador, não o backend inteiro.
Conferido em 2026-10-29. Cada ferramenta leva à fonte pública que mostra o uso.
