Cómo Patreon escaló su sistema de notificaciones con fanout

• El sistema de 13 años que venía procesando decenas de miles de millones de notificaciones al año empezó a topar con timeouts cuando un solo creador grande generaba millones, y Patreon lo rediseñó con una capa de fanout que pregenera notificaciones por destinatario
• Aplicó un fanout de 2 etapas que divide la lista de destinatarios en lotes pequeños y procesa de forma independiente el feed in-app, push y email, logrando escalabilidad horizontal y aislamiento de fallas por canal
• Para creadores grandes, las notificaciones push y el feed in-app se volvieron 80% más rápidos, y el email 55% más rápido; cuando la audiencia se cuadruplica, el aumento de la latencia de extremo a extremo bajó del 186% anterior a 33% y 60%, respectivamente
• Con Notification Factory y una API única send_fanout_notifications, estandarizó el filtrado, las verificaciones de elegibilidad y la generación de payloads, y simplificó la operación y depuración al rastrear tiempos por etapa y resultados por destinatario
• 10 equipos y más de 30 ingenieros migraron más de 200 notificaciones, y la generación de borradores basada en IA junto con una fecha límite clara definida por liderazgo ayudaron a reducir el trabajo repetitivo y la operación paralela prolongada

---

Los límites de escalado que revelaron los creadores grandes

• Patreon envía a los fans decenas de miles de millones de notificaciones al año cuando los creadores publican posts o inician livestreams
• Con el lanzamiento y crecimiento de las membresías gratuitas, el número de fans por creador aumentó drásticamente, y a inicios de 2025 aparecieron cuellos de botella graves de rendimiento, sobre todo con creadores grandes
• Las notificaciones de posts existentes tenían una estructura en la que una sola tarea asíncrona obtenía todos los destinatarios, los filtraba según la configuración de cada usuario, generaba el payload de cada destinatario y luego lo pasaba a los sistemas de entrega de feed in-app, push y email
• En el caso de creadores grandes, una sola tarea se encargaba de generar millones de notificaciones, lo que provocaba timeouts constantes y hacía difícil entregar notificaciones de forma confiable a audiencias masivas
• El flujo existente tenía dos límites estructurales
  • El costo de generación por destinatario se concentraba en una sola tarea asíncrona, lo que hacía imposible el escalado horizontal y creaba un límite claro de throughput
  • El feed in-app, push y email estaban fuertemente acoplados, de modo que la falla de un canal podía bloquear también a los demás
• Varios equipos de producto resolvieron problemas de corto plazo creando enfoques de escalado separados para cada notificación de alto volumen, pero eso aumentó la complejidad de la plataforma y dificultó el desarrollo, la operación y la depuración
• Decidieron mantener el sistema de entrega existente, pero colocar delante una capa de fanout común que ofreciera escalabilidad horizontal, aislamiento de canales y observabilidad

Seis condiciones de diseño para la plataforma de fanout

• La nueva capa se diseñó para dividir listas grandes de destinatarios en lotes pequeños, generar notificaciones por destinatario y luego entregarlas a los sistemas existentes de feed in-app, push y email
• Se aplicaron estos seis requisitos a la plataforma
  • Amigable para desarrolladores: cada notificación de alto volumen no debía tener que resolver escalabilidad y confiabilidad desde cero, y la plataforma debía reducir errores de uso mientras soportaba casos diversos
  • Escalabilidad horizontal: las listas de destinatarios debían dividirse automáticamente en lotes pequeños y procesarse de forma asíncrona
  • Aislamiento de canales: el feed in-app, push y email debían ejecutarse de forma independiente para que la falla de un canal no se propagara a otros
  • Procesamiento por prioridad: las notificaciones sensibles al tiempo debían separarse de las notificaciones generales usando colas y pools de workers dedicados
  • Observabilidad: debía ser posible investigar resultados de filtrado y entrega, y medir la latencia de todo el ciclo de vida de una notificación
  • Extensibilidad: debían poder agregarse funciones futuras, como la generación de listas de destinatarios, sin otro refactor masivo

Separar la lógica de negocio con Notification Factory

• Para separar la orquestación de la plataforma de la lógica de negocio específica de cada notificación, introdujeron la abstracción Notification Factory
• Cada factory funciona como un plano del procesamiento de notificaciones y define lo siguiente
  • Prioridad de procesamiento
  • Configuración de notificaciones que se aplicará
  • Método de filtrado de destinatarios
  • Verificaciones de elegibilidad específicas de la notificación
  • Método de generación de payload por canal
• Este patrón se basa en el motor de tareas distribuidas propio de Patreon y comparte varios conceptos
• El modelo Notification define argumentos de trabajo con datos únicos de una notificación específica que comparten todos los destinatarios
• La subclase conectada de BaseNotificationFactory actúa como procesador de la tarea e incluye la configuración y los métodos para filtrar destinatarios y generar notificaciones
• Para que una tarea de fanout que solo recibe un payload de notificación serializado pueda encontrar la lógica de negocio que debe ejecutar, usan un registry que mapea cada modelo Notification a su clase factory correspondiente
• Debían soportar distintos tipos de notificación y, al mismo tiempo, evitar errores comunes de implementación y consultas de datos ineficientes
  • Como Patreon tiene varios tipos de registros de usuario y métodos de filtrado, generalizaron la interfaz de destinatarios
  • Ofrecieron hooks claros para implementar configuraciones de usuario y verificaciones de elegibilidad específicas de cada notificación

API única y fanout de 2 etapas

• Antes se usaban APIs de envío separadas por canal, lo que podía hacer que los flujos de feed in-app, push y email divergieran, y obligaba a los equipos de producto a considerar comportamientos específicos por canal demasiado temprano
• Tras el rediseño, unificaron el punto de entrada en una sola API, send_fanout_notifications
  • El llamador pasa el payload de la notificación, la lista de destinatarios y un timestamp para medir la latencia de entrega
  • La API encuentra la factory de esa notificación, determina el tamaño de lote y la prioridad, y luego distribuye tareas por canal de forma independiente
  • La falla o demora de un canal no bloquea a los demás
• La primera etapa se encarga de escalar la generación de notificaciones
  • Divide toda la lista de destinatarios en lotes pequeños
  • Cada lote es procesado por una tarea FanoutNotifications
  • La tarea filtra destinatarios, ejecuta verificaciones de elegibilidad específicas de la notificación y luego genera payloads por canal mediante Notification Factory
• La segunda etapa se encarga de escalar la transferencia a entrega
  • Vuelve a hacer fanout de las notificaciones generadas hacia tareas de entrega dedicadas a feed in-app, push y email
• El procesador central de tareas FanoutNotifications se ubica entre la API y los sistemas existentes de entrega por canal, y convierte una única tarea enorme en muchas tareas pequeñas que pueden procesarse de forma independiente

Observabilidad y depuración a nivel de destinatario

• Las notificaciones pueden fallar o saltarse por muchas razones, como que el usuario haya desactivado una configuración, no pase una verificación de elegibilidad o no se pueda entregar a una dirección de email
• En la plataforma anterior, para verificar el resultado de procesamiento de una notificación específica había que combinar logs y datos de varios sistemas, y como no existía un rastreo integral de ejecución por destinatario, la investigación podía tomar horas
• La nueva plataforma se diseñó para poder responder estas preguntas
  • Cuánto tardó el envío de la notificación
  • Qué tan grande era la lista inicial de destinatarios
  • Cuántas personas fueron filtradas y por qué motivo
  • Cuántas se enviaron correctamente por canal
  • Por qué un usuario específico recibió o no recibió una notificación específica
• Introdujeron un modelo de datos de timing y logging que se transmite por toda la plataforma
  • Registra timestamps en cada etapa del flujo de notificación
  • Genera métricas y eventos tanto para resultados agregados como para resultados por destinatario
  • Los desarrolladores pueden agregar atributos de logging para incluir entidades relacionadas en los rastreos de ejecución y eventos
• Con mejoras en observabilidad, alertas, dashboards y herramientas de depuración, los ingenieros de producto y el equipo de soporte pueden investigar más problemas sin depender de ingenieros de plataforma

Migración de más de 200 notificaciones

• Como el patrón Notification Factory cambió la forma misma de desarrollar y mantener notificaciones, no era posible migrar solo con una herramienta de transformación de código (codemod)
• Había que preservar tal cual la lógica de negocio, las dependencias de datos, las reglas de elegibilidad y el comportamiento por canal de cada notificación
• A partir de la documentación de migración y de PRs ejemplares de migraciones manuales, crearon una habilidad de IA
  • Los desarrolladores podían ejecutar /migrate-notif-fanout <notif_name> para generar un primer resultado de migración
  • Fue efectiva para tareas repetitivas como crear el modelo de notificación, conectar la factory, modificar puntos de llamada y aplicar patrones de la plataforma
• La IA podía pasar por alto lógica de negocio sutil, alucinar o generar código duplicado que requería limpieza, así que no reemplazó el criterio de los ingenieros
• Migraron más de 200 notificaciones y, mediante una colaboración a gran escala que incluyó el uso de IA, completaron el 80% restante en 6 semanas

Mejoras de rendimiento e impacto en el desarrollo de producto

• Al mover la generación de notificaciones por destinatario a tareas escalables horizontalmente, pudieron generar de forma confiable millones de notificaciones por creador sin timeouts
• El rendimiento de las notificaciones de alto volumen para creadores grandes mejoró de forma significativa
  • Las notificaciones push y de feed in-app se volvieron 80% más rápidas
  • Las notificaciones por email se volvieron 55% más rápidas
  • Cuando la audiencia se cuadruplica, la latencia de extremo a extremo de push y feed in-app aumenta 33%, y la de email 60%
  • En las mismas condiciones, el aumento de latencia de la plataforma anterior era de 186%
• Los equipos de producto ya no necesitan diseñar una solución de escalado aparte para cada notificación de alto volumen, y la velocidad de desarrollo también mejoró
• La nueva plataforma dio soporte a lanzamientos clave de 2025 como Lives, Quips y la incorporación de creadores grandes
• Sin el rediseño de fanout, esos lanzamientos habrían chocado con los cuellos de botella existentes y requerido tiempo adicional de ingeniería para crear soluciones de escalado puntuales
• Con métricas de timing por etapa, pueden identificar dónde se consume el tiempo y ajustar la infraestructura según el equilibrio entre velocidad y costo

9 meses de operación paralela y coordinación organizacional

• La parte más difícil fue coordinar migraciones de varios equipos mientras se modificaba un sistema legacy en operación
• Operaron dos sistemas de notificaciones en paralelo durante 9 meses
  • Todos los cambios de plataforma debían ser compatibles tanto con la ruta existente como con la nueva ruta de fanout
  • Aumentó la superficie donde podían aparecer bugs e incidentes, y cuanto más se prolongaba la migración, más crecía el riesgo operativo
  • Hubo varios incidentes pequeños por problemas de compatibilidad, lo que aumentó la necesidad de terminar la migración de forma rápida y segura
• Al principio eligieron un enfoque bottom-up, en el que cada equipo de producto priorizaba por su cuenta la migración de sus notificaciones
  • En 6 meses solo migraron alrededor del 20%
  • El avance fue lento porque el trabajo quedaba desplazado por los roadmaps de producto y otras prioridades de los equipos
• Después de que el liderazgo de ingeniería acordó completar el trabajo en el primer trimestre de 2026 y asignó una fecha límite clara y prioridad para toda la compañía, completaron las migraciones restantes en 6 semanas
• En total participaron 10 equipos y más de 30 ingenieros
  • Gestionaron el avance con un tracker en Notion y automatización
  • Se comunicaron con frecuencia con stakeholders y distribuyeron el trabajo entre varios equipos
  • El equipo de plataforma realizó aproximadamente la mitad de las migraciones y luego pasó el despliegue y la limpieza a los equipos propietarios de cada notificación
  • Distribuyeron la carga para que el trabajo no se concentrara en equipos con muchas notificaciones
• Organizaron una semana de migración de notificaciones con office hours, leaderboard, premios y happy hour para acelerar el avance y celebrar la finalización
• Aseguraron un margen terminando el traspaso 2 semanas antes de la fecha límite total
  • Ayudaron a equipos que necesitaban soporte adicional y buscaron tareas faltantes en el codebase
  • En la revisión final encontraron 4 migraciones nuevas necesarias y varios pendientes, y los cerraron con solo un impacto menor en el cronograma

Lecciones de una migración de plataforma a gran escala

• Sin prioridades explícitas, las migraciones que atraviesan varios equipos compiten con los roadmaps de cada equipo y se postergan fácilmente
  • Esto se nota especialmente en la cola larga de notificaciones de bajo volumen, donde el impacto de escalado es menos evidente
  • El acuerdo del liderazgo, una prioridad compartida y una fecha límite clara fueron importantes para completar la migración en un plazo razonable

• El trabajo de plataforma no termina en la API

  • Antes, investigar preguntas de notificaciones y problemas de entrega de otros equipos ocupaba una parte considerable del trabajo on-call de los ingenieros de plataforma
  • También hay que mejorar observabilidad, alertas, dashboards y herramientas de depuración para que los equipos de producto y soporte puedan investigar de forma independiente y se reduzca la carga del on-call de plataforma
  • Hay que considerar no solo el cuello de botella actual, sino también el siguiente cuello de botella
  • Un solo proyecto no podía resolver todos los problemas de escalado de notificaciones
  • Diseñaron la plataforma para poder incorporar funciones futuras y reducir la probabilidad de necesitar otro refactor masivo cuando aumente el volumen de notificaciones

El próximo cuello de botella y planes futuros

• Aunque escalaron la generación de notificaciones, el siguiente cuello de botella es la generación de listas de destinatarios
• A medida que el público objetivo de las notificaciones siga creciendo, será cada vez más importante consultar de forma eficiente a millones de destinatarios
• Planean incluir la generación de listas de destinatarios en Notification Factory para que la plataforma se encargue de una mayor parte del flujo de notificaciones de extremo a extremo
• También mejorarán la configuración de notificaciones tanto para desarrolladores como para fans
  • Ayudarán a los desarrolladores a crear y administrar nuevas configuraciones con más facilidad
  • Harán que los fans puedan entender y controlar con más facilidad sus preferencias de notificaciones