Construyendo Orkesta: notas de ingeniería de una plataforma multi-tenant

Todo evento termina igual: una persona en la puerta con una lista impresa y un teléfono, tratando de cuadrar el Excel de invitados, la libreta del acomodo de mesas y un chat de WhatsApp lleno de “¿ya confirmaste?”. Tres herramientas que nunca coinciden y se desincronizan justo cuando más aprieta la presión. Orkesta es lo que construí para unir las tres en un solo flujo — y estas son las notas de ingeniería de haberlo hecho.

El problema no son las funciones, es la coordinación

Los organizadores para los que construí no necesitan otra app. Necesitan que cada pregunta — quién viene, con cuántos acompañantes, en qué mesa, quién entró de verdad — viva en un solo lugar y siga sincronizada desde la invitación hasta el check-in. Así que no arranqué de una lista de funciones. Arranqué de la pregunta: ¿qué tiene que ser cierto para que el día del evento no se derrumbe? Todo lo que no servía a eso, no se construyó.

Multi-tenant desde la primera línea

La primera decisión real fue tratar a Orkesta como un SaaS multi-tenant de verdad desde el inicio, no como un demo de un evento que “ya escalaré después”. Varios organizadores, cada uno con sus eventos y sus datos aislados, y cuatro roles — admin de plataforma, organizador, staff de check-in, invitado — aplicados en el servidor, no solo ocultos en la interfaz. Meter el aislamiento por tenant a posteriori es reescribir; cocinarlo en el modelo de datos y en cada query desde el día uno es simple disciplina.

Si la autorización solo vive en el frontend, no existe. Cada endpoint protegido verifica rol y ownership.

El stack, y por qué cada pieza se gana su lugar

• Angular 19 + SSR. La invitación pública es la única página que tiene que cargar rápido en el teléfono, porque ahí justo la abren los invitados. El renderizado en servidor compra ese primer pintado en vez de mandar una pantalla en blanco.
• NestJS en TypeScript estricto. Una API REST documentada con control de acceso por roles aplicado del lado del servidor. Tipos estrictos de punta a punta significa que el contrato entre front y back se verifica en build, no se descubre en producción.
• Prisma + PostgreSQL. Un modelo relacional encaja con el dominio — los organizadores tienen eventos, los eventos tienen invitados, los invitados se asignan a mesas. Prisma mantiene ese esquema tipado y las migraciones honestas.
• Redis. Los reportes y las notificaciones no van en el camino del request. Empujar ese trabajo al segundo plano mantiene la API ágil cuando una lista grande confirma de golpe.
• JWT de acceso + refresh. Tokens de acceso de vida corta, refresh para la continuidad — estándar, aburrido, y exactamente lo que la auth debe ser.

Nada exótico. Todo el punto era una base que pueda razonar bajo presión.

Qué aprendí

Ser dueño del stack completo cambia cómo decides. No hay a quién pasarle el problema del backend cuando el frontend lo necesita resuelto — así que lo resuelves, y lo resuelves bien, porque tú vas a vivir con esa decisión. Esa presión es una ventaja: mata los atajos que de otro modo te justificarías.

La invalidación de cache es el impuesto silencioso. Mover trabajo a Redis es fácil; asegurar que se recalcule lo correcto cuando cambia el estado es la parte que de verdad se gana el rendimiento. Prefiero pagar ese costo a propósito que entregar una API rápida que miente sobre cuántos invitados llegaron.

Las restricciones aclaran. “¿Qué tiene que ser cierto para que el día no se derrumbe?” resultó ser una herramienta de diseño más afilada que cualquier backlog de funciones. Es la misma pregunta a la que sigo volviendo — y es por la que Orkesta es un producto corriendo en producción, no un prototipo que siempre pienso terminar.