Boty Discord

Die Communitys unserer Marken leben auf Discord, nicht auf einer Website. Dort landet ein neuer Kunde, dort öffnet er ein Ticket, dort wartet er auf die Rolle, die Zugang zu den richtigen Kanälen gibt. Bei einigen hundert Mitgliedern hört das manuelle Bewältigen von Tickets, Willkommensnachrichten und Rollen einfach auf zu funktionieren - jemand muss da sein, hinschauen und klicken, und das skaliert nicht mit der Zahl der Leute.

Statt einen universellen Bot für alles zu schreiben, haben wir einen Kern und einen Satz von Modulen gebaut, aus denen jeder Bot einzeln zusammengesetzt wird. Vier Server, vier Rollen, vier Konfigurationen - aber ein Ort, an dem die Logik lebt. Diese Fallstudie handelt davon, warum sich diese Aufteilung mehr gelohnt hat als ein Monolith, der am Anfang bequem gewesen wäre.

Es ist verlockend, einen Bot zu schreiben, der die ganze Arbeit auf allen Servern erledigt. Das Problem ist, dass jeder Server etwas andere Bedürfnisse hat: ein anderes Team für den Ping beim Ticket, einen anderen Beitrittsweg für ein neues Mitglied, andere Rollen und eine andere Verifizierungsschwelle. Ein universeller Bot, der sie alle bedienen soll, wird mit der Zeit zu einem Weihnachtsbaum aus Flags, an dem niemand etwas anfassen will, weil unklar ist, was sonst noch davon abhängt.

Die zweite Falle ist der gemeinsame Zustand. Ein Prozess, der vier Server gleichzeitig bedient, ist ein einziger Ausfallpunkt - ein Fehler in der Ticket-Logik kann die Willkommensnachrichten auf einem völlig anderen Server lahmlegen. Und je mehr ungenutzten Code ein Server mit sich führt, desto schwerer ist es, in ihm irgendetwas sicher zu ändern.

Wir sind den anderen Weg gegangen: ein Kern mit Modulen, die im Discord-Ökosystem Cogs heißen, und jeder Bot ist ein Satz aktivierter Cogs. Der Ticket-Server nimmt den Ticket-Cog; ein Server, der ihn nicht braucht, schaltet ihn einfach nicht ein.

In der Praxis ist das Ökosystem vier getrennte Bots, von denen jeder eine Sache ordentlich macht. Der Ticket-Bot öffnet Ticket-Threads und pingt das richtige Team, damit ein Anliegen nicht ins Leere läuft. Der Willkommens-Bot führt ein neues Mitglied durch die ersten Schritte. Der Verify-Bot bestätigt beim Beitritt eine E-Mail-Adresse. Der Rollen-Bot hält die Rollenhygiene und vergibt sie automatisch.

Diese Aufteilung ist nicht kosmetisch. Jeder Bot hat seinen eigenen Berechtigungsumfang und seinen eigenen Zustand, sodass der Ausfall eines nicht die übrigen mitreißt und eine Änderung in einem nicht bedeutet, über die drei anderen nachdenken zu müssen. Gemeinsam ist nur der Kern - wie ein Cog sich in den Bot einklinkt, wie er die Konfiguration liest und wie er mit der API spricht.

Ein Cog ist eine abgeschlossene Einheit: eigene Befehle, eigene Listener, eigener Zustand. Sie klinken ihn mit einer Zeile in den Bot ein und ebenso wieder aus. Es gibt kein globales Geflecht - der Ticket-Cog weiß nichts vom Rollen-Cog und muss es nicht. Unten ein Ausschnitt der Verifizierung: ein neues Mitglied bekommt eine Warterolle und eine Aufforderung, seine Adresse zu bestätigen, bevor es den Rest des Servers sieht.

Namen wie on_member_join oder add_roles gibt die Discord-API vor und bleiben, wie sie sind - der Rest der Bezeichner folgt unserer eigenen Konvention. Das ist die Grenze, an der man der Bibliothek folgt, nicht dem eigenen Stil, und die einzige Stelle, an der sich zwei Namenskonventionen mischen.

Der größte Gewinn ist nicht auf dem Server sichtbar, sondern darin, wie diese Bots gewartet werden. Eine Korrektur in der Ticket-Logik landet an einer Stelle und erreicht überall dort, wo dieser Cog aktiviert ist - Sie schreiben sie nicht viermal und vergessen nicht einen Server. Kein Server führt Code mit, den er nicht nutzt, sodass seine Konfiguration genau so komplex ist wie seine echten Bedürfnisse.

Einen fünften Server hinzuzufügen bedeutet nicht, einen fünften Bot von Grund auf zu schreiben. Man setzt ihn aus dem zusammen, was schon da ist: man nimmt die passenden Cogs, stellt die Konfiguration ein, und das war es. Das ist der Unterschied zwischen vier getrennten Projekten und einem Ökosystem, das durch Hinzufügen von Modulen wächst, nicht durch Vervielfachen von Code.