Boty Discord

Las comunidades de nuestras marcas viven en Discord, no en una web. Ahí llega un nuevo cliente, ahí abre un ticket, ahí espera el rol que da acceso a los canales adecuados. Con unos cientos de miembros, gestionar a mano los tickets, las bienvenidas y los roles simplemente deja de sostenerse - alguien tiene que estar ahí, mirar y hacer clic, y eso no escala con el número de personas.

En lugar de escribir un bot universal que lo haga todo, construimos un núcleo y un conjunto de módulos con los que cada bot se ensambla por separado. Cuatro servidores, cuatro roles, cuatro configuraciones - pero un solo lugar donde vive la lógica. Este caso de estudio trata de por qué esa división rindió más que un monolito que habría sido cómodo al principio.

Es tentador escribir un bot que haga todo el trabajo en cada servidor. El problema es que cada servidor tiene necesidades algo distintas: un equipo distinto al que pingar en un ticket, un recorrido de entrada distinto para un nuevo miembro, roles distintos y un umbral de verificación distinto. Un bot universal que pretenda gestionarlos todos se convierte con el tiempo en un árbol de Navidad de flags que nadie quiere tocar, porque no se sabe qué más depende de ellos.

La segunda trampa es el estado compartido. Un proceso que sirve a cuatro servidores a la vez es un único punto de fallo - un error en la lógica de tickets puede tumbar las bienvenidas en un servidor completamente distinto. Y cuanto más código sin usar carga un servidor, más difícil es cambiar en él cualquier cosa con seguridad.

Fuimos por el otro lado: un núcleo con módulos, que en el ecosistema de Discord se llaman cogs, y cada bot es un conjunto de cogs activados. El servidor de tickets toma el cog de tickets; un servidor que no lo necesita simplemente no lo activa.

En la práctica el ecosistema son cuatro bots separados, cada uno haciendo una cosa bien. El bot de tickets abre hilos de tickets y pinga al equipo adecuado para que un aviso no se quede en el vacío. El bot de bienvenida guía a un nuevo miembro por sus primeros pasos. El bot de verificación confirma una dirección de correo al entrar. El bot de roles mantiene la higiene de los roles y los asigna automáticamente.

Esta división no es cosmética. Cada bot tiene su propio ámbito de permisos y su propio estado, de modo que el fallo de uno no arrastra al resto, y un cambio en uno no obliga a pensar en los otros tres. Solo el núcleo es común - cómo un cog se engancha al bot, cómo lee la configuración y cómo habla con la API.

Un cog es una unidad autónoma: sus propios comandos, sus propios listeners, su propio estado. Lo enganchas al bot en una línea y lo desenganchas igual. No hay maraña global - el cog de tickets no sabe nada del cog de roles y no lo necesita. Abajo un fragmento de la verificación: un nuevo miembro recibe un rol de espera y una invitación a confirmar su dirección antes de ver el resto del servidor.

Nombres como on_member_join o add_roles los impone la API de Discord y quedan tal cual - el resto de los identificadores sigue nuestra propia convención. Es la frontera en la que sigues la biblioteca, no tu propio estilo, y el único lugar donde se mezclan dos convenciones de nombres.

La mayor ganancia no es visible en el servidor sino en cómo se mantienen estos bots. Una corrección en la lógica de tickets aterriza en un solo lugar y alcanza dondequiera que ese cog esté activado - no la reescribes cuatro veces ni olvidas un servidor. Ningún servidor carga código que no usa, así que su configuración es exactamente tan compleja como sus necesidades reales.

Añadir un quinto servidor no significa escribir un quinto bot desde cero. Se ensambla a partir de lo que ya existe: tomas los cogs que encajan, ajustas la configuración, y ya está. Esa es la diferencia entre cuatro proyectos separados y un ecosistema que crece añadiendo módulos, no multiplicando código.