Slack und GitHub skalieren: Emoji-Limit, Lasttest und Scatter Queries

Maude Lemaire ist Principal Engineer und Autorin von „Refactoring at Scale". Sie war knapp acht Jahre bei Slack, ging 2024 zu GitHub und arbeitete zuletzt bei Cursor. In der Folge „Scaling Slack and GitHub with Maude Lemaire" von Gergely Orosz (5. November 2026, 78 Minuten) erzählt sie von einem Emoji-Limit, einem Lasttest mit 500.000 WebSocket-Verbindungen und 16 Datenbank-Shards. Eine Newsletter-Zusammenfassung nennt dazu mehrere Zahlen. Wir haben sie gegen das Transkript der Folge und gegen Slacks eigene Texte gelegt.

Ein Thundering Herd ist ein Lastspitzen-Muster: Ein Ereignis löst bei sehr vielen Clients gleichzeitig dieselbe Aktion aus, und das System fängt die Summe nicht ab. Bei Slack ist es die Nachricht an einen großen Kanal, auf die Tausende im selben Moment reagieren. Jede Reaktion wird an alle verbundenen Nutzer weitergereicht, die Last wächst mit dem Produkt aus Reagierenden und Empfängern.

Das Emoji-Limit

Lemaires Beispiel: Ein CEO schreibt in einen Firmenkanal mit etwa 100.000 aktiven Nutzern, alle bekommen Freitag frei. Jeder öffnet den Kanal, liest die Historie und setzt ein Emoji, laut Folge innerhalb derselben fünf Sekunden. Jede Reaktion geht über den WebSocket an alle. Ein Emoji ergibt 100.000 Zustellungen, und „if you add 10, you can do the math". Slack hatte Emojis schon vorher niedriger priorisiert als Textnachrichten und warf sie bei hoher Last weg.

Die Zahl „10 Millionen bei 100 Emojis" steht in der Newsletter-Zusammenfassung und fehlt im Transkript. Sie ist 100 mal 100.000 und damit korrekt gerechnet, aber die Rechnung stammt vom Newsletter.

Zum Limit sagt Lemaire: Man könne 23 verschiedene Custom-Emojis als Reaktion auf eine Nachricht setzen, aber beliebig viele Plus-Eins auf diese Emojis. Sie schränkt ein: „last I checked". Die Slack-Hilfeseite zu Reaktionen sagt etwas anderes: Jedes Mitglied könne bis zu 23 Reaktionen auf eine Nachricht setzen, insgesamt höchstens 50 verschiedene Emojis. Die API-Dokumentation kennt zwei getrennte Fehler, too_many_emoji für die Grenze verschiedener Emojis und too_many_reactions für die Grenze je Person, nennt aber keine Zahlen. Die Hilfeseite, die wir lesen konnten, liegt auf einer Sandbox-Domain von Slack und ist undatiert. Welche Zahl heute gilt, haben wir nicht festgestellt.

Der Lasttest ohne Headless Chrome

Für einen Kunden mit 500.000 Nutzern brauchte Slack 500.000 offene WebSocket-Verbindungen. Die vorhandene Lösung startete Slack als Headless Chrome in Kubernetes-Pods. Laut Lemaire kostete eine Instanz 37 Cent je fünf Stunden Testfenster. Für den ganzen Test nennt sie „$150,000 for that one test". Sie sagt auch, dass die Hälfte der Zeit dafür draufging, abgestürzte Pods neu zu starten.

Die Beträge lassen sich nicht nachprüfen. 500.000 Instanzen zu 0,37 US-Dollar wären 185.000 US-Dollar, das passt nicht zu 150.000. Welche Instanzzahl hinter dem Betrag steckt, sagt die Folge nicht. Die Newsletter-Version („Maude built Koi Pond") ist ebenfalls ungenau: Der Slack-Blogbeitrag von Shreya Ramesh nennt Lemaire unter den fünf Namen des Teams, dem er am Ende dankt.

Ersetzt wurde Headless Chrome durch viele kleine Go-Prozesse, die je eine WebSocket-Verbindung halten und API-Aufrufe wie ein echter Client absetzen, mit geringerer Wiedergabetreue. Das Werkzeug heißt Koi Pond. Slack beschreibt es selbst: Eine „School" steuert bis zu 5.000 simulierte Clients, der größte Test lief mit 2 Millionen Nutzern in einem Workspace. Laut Slack kosten 2 Millionen Nutzer in Koi Pond etwa 0,26 Prozent dessen, was 150.000 Nutzer mit dem Headless-Chrome-Werkzeug Puppet Show kosten. Das ist eine Herstellerangabe aus dem Jahr 2021, aktualisiert 2023.

GitHub: 16 Shards und Scatter Queries

Als Lemaire zu GitHub kam, sah sie für alle Pull Requests und Issues 16 Shards im Vitess-Setup. Das sei nicht viel, sagt sie, und die Antwort auf die Frage nach dem Grund sei zum Teil gewesen: mehr Shards gehe nicht, weil es schon so viele Scatter Queries gebe. Ihr Beispiel, alle Pull Requests eines Autors, nannte sie selbst hypothetisch. Sie sagt außerdem „I don't know if this is still the case".

Warum man Scatter Queries nicht einfach entfernen kann, erklärt sie mit Active Record. Die Abstraktion verbirgt die SQL-Abfrage: Eine Funktion mit fünf Zeilen, und niemand findet die Stelle, an der abgefragt wird. Als Beispiel für die Last nennt sie die Repository-Startseite mit der README. Beim letzten Blick vor ihrem Weggang habe sie über 100 MySQL-Abfragen über mindestens drei Cluster ausgelöst, und fast jede Zahl auf einer GitHub-Seite werde live gezählt. Der Newsletter macht daraus „home page" und „~100". Gemeint ist die Repository-Seite, und es waren mehr als 100.

Ein Scatter Query ist eine Abfrage an eine in Shards geteilte Datenbank, die den Sharding-Schlüssel nicht enthält. Der Router weiß dann nicht, wo die Daten liegen, und schickt sie an alle Shards. Mit jedem weiteren Shard steigt der Aufwand pro Abfrage, obwohl jeder Shard weniger Daten hält. Das erklärt, warum 16 Shards festhielten. Sie bezeichnet es allerdings nur als Teil der Erklärung, der Newsletter macht daraus eine feste Obergrenze.

Was belegt ist und wo

Alle Zeitangaben beziehen sich auf das Transkript. Gemessen haben wir nichts davon. Die Aussagen über GitHub stammen von einer früheren Mitarbeiterin.

Was sich daraus für den eigenen Betrieb ableiten lässt

Zwei Prüfungen brauchen weder Slack-Größe noch Sharding. Erstens: Welche Aktion kann bei vielen Nutzern gleichzeitig dasselbe auslösen, und was fließt dann an alle zurück? Eine harte Obergrenze wie bei den Reaktionen ist laut Lemaire eine Produktentscheidung, keine reine Technikfrage. Zweitens: Welche Abfragen laufen ohne den Schlüssel, nach dem die Daten verteilt sind? Diese Liste sollte vor dem nächsten Shard vorliegen. Ein Beispiel für feste statt freier Abfragen steht im Beitrag über Googles MCP Toolbox mit vordefinierten SQL-Abfragen für Agenten. Weitere Beiträge zu Servern, Betrieb und Netzwerk sammelt der Hub Server und Netzwerk, unser Angebot steht unter Leistungen.

Offen bleibt, ob Lemaires Zahlen heute noch gelten. Beide Aussagen über GitHub tragen den Vorbehalt „last I checked", und bei Slack widersprechen sich Folge und Hilfeseite.

Weiterführende Quellen

• Shownotes der Folge: newsletter.pragmaticengineer.com
• Folge auf YouTube: youtu.be/x6WqD4qHxSc
• Slack Engineering, Koi Pond: Load Testing with Koi Pond
• Slack API, Fehler too_many_emoji und too_many_reactions: reactions.add
• Slack-Hilfe, Emoji-Reaktionen (Sandbox-Domain): Emoji reactions
• Allgemeine Erklärung: Thundering herd problem