¿Cómo construir un sistema de notificaciones push escalable?

Las notificaciones push están en todas partes, ya sea una alerta de noticias de última hora, una actualización meteorológica o un mensaje de “su pedido ha enviado”, impulsan el compromiso y ofrecen valor en tiempo real a los usuarios. Pero diseñar un sistema de notificación push que pueda manejar miles de millones de mensajes en las plataformas, mientras permanece performre y confiable, no es caminar en el parque.

Las aplicaciones modernas a menudo necesitan impulsar información sensible al tiempo a los usuarios en dispositivos móviles (iOS/Android), escritorios (macOS/Windows) y navegadores (Chrome, Firefox, Safari). Cada una de estas plataformas viene con su propio protocolo, limitaciones de entrega y límites de tarifas. Ahora cubra reglas comerciales como preferencias de usuario, segmentación, estrangulamiento, reintentos y localización: de repente está mirando un sistema distribuido no trivial.

Una implementación básica puede funcionar a baja escala o en una prueba de concepto. Pero, ¿qué sucede cuando tienes 50 millones de usuarios, cada uno con múltiples dispositivos y marketing quiere ejecutar campañas al 10% de tu audiencia cada pocos minutos? Ahí es donde las cosas comienzan a desmoronarse si su arquitectura no fue construida para ella desde cero.

Esta guía atraviesa el plan arquitectónico de construir un sistema de notificación escalable, tolerante y extensible de push. Se centrará en la entrega multiplataforma (APNS, FCM, WebPush), preocupaciones a nivel de sistema como colas y reintentos, así como cómo sintonizar el rendimiento bajo alta carga.

El objetivo es equiparlo con el modelo mental y los patrones de diseño necesarios para construir un sistema que no se dobla bajo presión, y puede evolucionar con las necesidades de su producto.

Requisitos del sistema

Requisitos funcionales

En esencia, el sistema de notificación push debe entregar mensajes a los dispositivos de usuario final. Pero “entrega” no es suficiente. Esto es lo que el sistema debería hacer:

• Entrega multiplataforma: Admite el Servicio de Notificación de Push Apple (APNS), Mensajería Cloud Firebase (FCM) y Protocolo de Push Web (WPP).
• Registro y gestión del dispositivo: Almacene los tokens del dispositivo asignados a usuarios, plataformas y aplicaciones.
• Capacidades de orientación: Envíe mensajes a usuarios específicos, grupos de dispositivos, segmentos de usuario o todos los usuarios (transmisión).
• Programación: Permita que los mensajes se envíen de inmediato o en un futuro tiempo programado.
• Limitación de tasas: Mensajes de aceleración basados ​​en restricciones de plataforma o reglas comerciales internas.
• Reintento de lógica: Vuelva a intentar automáticamente las entregas fallidas con políticas exponenciales de retroceso o reintento personalizado.
• Preferencias de usuario: Respeta el estado de opción/exclusión, horas tranquilas o tipos de canales específicos (por ejemplo, promocional versus transaccional).
• Auditoría y análisis: Rastree el éxito/falla de la entrega, se abre (cuando sea posible) y metadatos de diagnóstico para la resolución de problemas.

Requisitos no funcionales

Estas son las preocupaciones de la columna vertebral: las fusiones, y su plataforma colapsará bajo el uso del mundo real.

• Escalabilidad: El sistema debe manejar picos de millones de mensajes por minuto.
• Disponibilidad: Se dirige al 99.99% de tiempo de actividad, especialmente para rutas críticas como el registro de dispositivos y las tuberías de entrega.
• Estado latente: Procesamiento sub-segundo para transaccional (por ejemplo, OTP, alertas de seguridad); Retraso tolerable (5-15) para mensajes de marketing por lotes.
• Durabilidad: Los mensajes no deben perderse en caso de nodo o falla del servicio.
• Seguridad: Protección de extremo a extremo de datos del usuario, autenticación a servicios de terceros, cifrado de cargas útiles en tránsito y en reposo.
• Multi-tenencia: Capacidad para admitir múltiples aplicaciones/clientes con datos aislados y tuberías de entrega.

Restricciones y supuestos

La definición de los límites es fundamental para reducir la ambigüedad arquitectónica.

• Suponga que los proveedores de empuje de la plataforma (APNS, FCM, WebPush) son externas y actúan como cajas negras con SLA publicados.
• Las cargas útiles de mensajes son pequeñas (2kb – 4kb), con la mayoría de las lógicas manejadas en el lado del cliente.
• Hay una plataforma de identidad de usuario existente que expone mapeaciones de dispositivo a usuario y preferencias de usuario.
• El sistema no garantizará la entrega, una vez que se entrega a APNS/FCM, la responsabilidad es suya.
• El sistema se ejecutará en un entorno nativo de nube (Kubernetes o contenedores administrados, autoscalado, etc.).

Caso de uso del núcleo y panorama de entrega

Antes de sumergirse en la arquitectura, es importante aclarar para qué resuelve este sistema, porque las “notificaciones de empuje” significan cosas diferentes en diferentes contextos comerciales. Esta sección explora el panorama operativo del mundo real, que usa el sistema y cómo la escala afecta las opciones de diseño.

Caso de uso comercial principal

Definamos un caso de uso típico de alto impacto: una plataforma de comercio electrónico B2C a gran escala quiere enviar notificaciones push en tiempo real en dispositivos móviles y web para impulsar la participación del usuario, alertar a los usuarios de las actualizaciones de estado del pedido o activar recordatorios basados ​​en el comportamiento (por ejemplo, desnudos de carritos abandonados). También hay casos de uso interno: alertas de OPS, sistemas de fraude e integraciones de socios. Pero el controlador central es mensajes de alto rendimiento y centrado en el usuario con diferentes niveles de criticidad.

Usuarios y canales de notificación

Los usuarios finales del sistema no son solo clientes que reciben los mensajes push. Hay múltiples actores:

• Vendedores: Ejecute campañas grandes, programas y cohortes de usuarios de segmento.
• Equipos de productos: Activar notificaciones contextuales del comportamiento de la aplicación (hitos en la aplicación, bucles de gamificación).
• Sistemas de backend: Activar automáticamente mensajes transaccionales como OTP, confirmaciones de pago o alertas de entrega.

En el extremo receptor, cada usuario puede tener múltiples tipos de dispositivos:

• Aplicaciones móviles: iOS a través de APN y Android a través de FCM.
• Navegadores web: A través del protocolo de push web (basado en VAPID), típicamente para usuarios de escritorio/computadora portátil.
• Servicios de terceros: En algunos casos, las integraciones con canales de entrega de terceros como WhatsApp o superposiciones de mensajería en la aplicación están involucradas, pero fuera de alcance para este sistema.

Consideraciones de volumen y escala

Esto es lo que se espera que el sistema maneje a escala del mundo real:

• 100m+ dispositivos registrados En todas las plataformas, con un 5-10% activo a diario.
• Eventos transaccionales: Mensajes/día de 3–5m, con SLA de latencia dura (por ejemplo, OTP en 3 segundos).
• Campañas: Burst envía a 10-20 millones de usuarios en menos de 5 minutos, a menudo activados a través del tablero o colas de trabajo de backend.
• Concurrencia máxima: 200k+ mensajes/minuto durante eventos tipo Black Friday o durante picos virales.

No se trata de enviar un mensaje a un usuario, se trata de enviar millones de mensajes a medida en miles de nodos, con confiabilidad, reintentos y retraso mínimo. El diseño debe acomodar este tipo de carga de trabajo dinámica, lo que significa servicios centrales sin estado, colas distribuidas y escalabilidad horizontal en cada nivel.

Arquitectura del sistema de alto nivel

La arquitectura para un sistema de notificación push escalable gira en torno a tres principios: desacoplamiento, paralelismo, y entrega específica de la plataforma. A escala, los diseños monolíticos se desmoronan, por lo que esta arquitectura abarca un enfoque basado en microservicios y basado en eventos que puede ventilarse, acelerar, volver a intentar y auditar miles de millones de mensajes con cuellos de botella mínimos. Pasemos por los subsistemas centrales, el flujo de datos y las abstracciones específicas de la plataforma que hacen que todo funcione.

Descripción general de los componentes

La arquitectura se divide en los siguientes componentes lógicos:

• API de ingestión: Recibe solicitudes de mensajes, batch o transaccional, validata la entrada, Enqueues los mensajes en la tubería.
• Motor de enrutamiento: Mira a los dispositivos, divide mensajes por par de plataformas de dispositivo, los enoja en las colas respectivas.
• Trabajadores de entrega de plataforma: Microservicios dedicados para APNS, FCM y WebPush. Estos manejan la gestión de la conexión, los reintentos, los lotes y la limitación de la velocidad.
• Cola de mensajes (capa de corredor): Broker de alto rendimiento (por ejemplo, Kafka, RabbitMQ o Google Pub/Sub) para los productores de desacoplamiento de la lógica de entrega.
• Servicio de registro de dispositivos: Almacena metadatos del dispositivo, asignaciones de usuarios, validez de token, tipo de plataforma y estado de opción.
• Motor de preferencias y reglas: Evalúa la configuración de notificación del usuario, reglas de supresión (horas de silencio, límites de frecuencia) o anulaciones específicas del canal.
• Programador: Para la entrega de mensajes retrasados ​​o basados ​​en la ventana de tiempo.
• Monitoreo y circuito de retroalimentación: Captura recibos de entrega a nivel de plataforma, errores y análisis; Maneja la retroalimentación de APN, desinstalaciones de FCM, etc.

Diagrama de arquitectura de alto nivel

                          +------------------+
                          |   Ingestion API  |
                          +--------+---------+
                                   |
                                   v
                          +---------------------+
                          |   Routing Engine    |
                          +--------+------------+
                                   |
                                   v
                          +---------------------+
                          |   Message Broker    |
                          | (Kafka / RabbitMQ) |
                          +--------+------------+
                                   |
        +--------------------------+--------------------------+
        |                          |                          |
        v                          v                          v
  +-------------+          +--------------+          +----------------+
  | APNs Worker |          | FCM Worker   |          | WebPush Worker |
  +------+------+          +------+-------+          +--------+-------+
         |                        |                           |
         v                        v                           v
+------------------+   +---------------------+    +------------------------+
| Apple Push Notif |   | Firebase Cloud Msg  |    | Web Push Service (VAPID)|
| Service (APNs)   |   | (FCM)               |    |                        |
+------------------+   +---------------------+    +------------------------+

        +------------------------+          +--------------------------+
        |  Device Registry Svc   | <------>  |  User Preferences Engine |
        +------------------------+          +--------------------------+

                          +---------------------------+
                          | Scheduler / Campaign Svc  |
                          +---------------------------+

                          +---------------------------+
                          | Monitoring / Analytics    |
                          | (Logs, Receipts, Metrics) |
                          +---------------------------+

Patrones arquitectónicos clave

• Arquitectura basada en eventos: El flujo de mensajes es completamente asincrónico. Los productores (API, sistemas internos) se desacoplan de la entrega utilizando colas de pub/subs o mensajes.
• Abstracción específica de la plataforma: Los trabajadores están a medida por plataforma. Cada uno administra sus propios límites de tarifa, formatos de carga útil, reintentos y API Auth.
• Soporte de backpressure: Los corredores de mensajes deben manejar sobretensiones sin soltar datos. El amortiguador, las colas de letras muertas y el autoscalaje del consumidor están integrados.
• Idempotencia y deduplicación: Los mensajes deben transportar ID únicas para evitar problemas de doble mensaje, especialmente en reintentos.
• Aislamiento de falla: Una interrupción de la plataforma (digamos, APNS) no debe cascade and Stall Mensajes para FCM/WebPush. Cada grupo de trabajadores está aislado y tolerante a fallas.

Esta arquitectura puede escalar horizontalmente cada componente de forma independiente: más trabajadores para APN durante las explosiones de la campaña de iOS, o más nodos de enrutamiento durante los picos de ingestión. Cada nivel se puede monitorear, acelerar o reiniciar sin afectar el sistema completo.

Diseño de base de datos y gestión de tokens

Los sistemas de notificación de push viven o mueren por su capacidad para administrar millones de tokens de dispositivos, preferencias de usuario y estados de mensaje de manera eficiente. Esta sección desglosa cómo diseñar un esquema de base de datos que escala horizontalmente, mantiene la consistencia de la entrega y admite la orientación y el filtrado en tiempo real.

Entidades de datos centrales

Como mínimo, se requieren las siguientes entidades:

• Usuarios: Identidad lógica del usuario (UID), vinculada a uno o muchos dispositivos.
• Dispositivos: Registros de dispositivos específicos de la plataforma con tokens, versión de aplicación, última vista, etc.
• Preferencias: Indicadores de opción/exclusión específicos del usuario, configuración de canales, horas de silencio, etc.
• Mensajes: Historial de notificaciones enviadas, su estado de entrega y metadatos para la resolución de problemas/auditoría.

Modelo de relación de entidad (ERD)

Así es como las entidades se relacionan a un alto nivel:

 
+--------+       1        +---------+       M        +-----------+
| Users  |---------------<| Devices |--------------->| Preferences|
+--------+                +---------+                +-----------+
   |                          |
   |                          | 1
   |                          |
   |                        M |
   v                          v
+-------------+         +--------------+
| Notifications|        | Delivery Logs|
+-------------+         +--------------+

Esquemas de tabla (simplificado)

 

users (
  id           UUID PRIMARY KEY,
  email        TEXT UNIQUE NOT NULL,
  created_at   TIMESTAMP DEFAULT NOW()
)

-- Index: unique email lookup
-- CREATE UNIQUE INDEX idx_users_email ON users(email);

devices (
  id            UUID PRIMARY KEY,
  user_id       UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  platform      ENUM('ios', 'android', 'web') NOT NULL,
  token         TEXT UNIQUE NOT NULL,
  app_version   TEXT,
  last_active   TIMESTAMP,
  is_active     BOOLEAN DEFAULT true,
  created_at    TIMESTAMP DEFAULT NOW()
)

-- Indexes:
-- CREATE INDEX idx_devices_user_platform ON devices(user_id, platform);
-- CREATE UNIQUE INDEX idx_devices_token ON devices(token);

preferences (
  id           UUID PRIMARY KEY,
  user_id      UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  channel      ENUM('transactional', 'marketing') NOT NULL,
  enabled      BOOLEAN DEFAULT true,
  quiet_hours  JSONB,
  updated_at   TIMESTAMP DEFAULT NOW()
)

-- Index: preference lookup
-- CREATE UNIQUE INDEX idx_prefs_user_channel ON preferences(user_id, channel);

notifications (
  id            UUID PRIMARY KEY,
  title         TEXT,
  body          TEXT,
  payload       JSONB,
  scheduled_at  TIMESTAMP,
  priority      ENUM('high', 'normal', 'low') DEFAULT 'normal',
  created_by    TEXT,
  created_at    TIMESTAMP DEFAULT NOW()
)

delivery_logs (
  id              UUID PRIMARY KEY,
  notification_id UUID NOT NULL REFERENCES notifications(id) ON DELETE CASCADE,
  device_id       UUID NOT NULL REFERENCES devices(id) ON DELETE CASCADE,
  status          ENUM('pending', 'delivered', 'failed', 'dropped') DEFAULT 'pending',
  attempt_count   INT DEFAULT 0,
  response_code   TEXT,
  error_message   TEXT,
  delivered_at    TIMESTAMP
)

-- Indexes:
-- CREATE INDEX idx_logs_device_status ON delivery_logs(device_id, status);
-- CREATE INDEX idx_logs_notif_status ON delivery_logs(notification_id, status);

Filas de muestra (solo ilustrativas)

 
users
--------------------------------------------------------------
id                                    | email
--------------------------------------+-------------------------
5b6e...d1                              | user@example.com

devices
--------------------------------------------------------------
id        | user_id  | platform | token         | is_active
----------+----------+----------+---------------+------------
f7a9...91 | 5b6e...d1| ios      | abc123token...| true

preferences
--------------------------------------------------------------
id        | user_id  | channel        | enabled | quiet_hours
----------+----------+----------------+---------+-------------
c1f3...72 | 5b6e...d1| marketing       | false   | {"start":"22:00","end":"07:00"}

notifications
--------------------------------------------------------------
id        | title          | priority | scheduled_at
----------+----------------+----------+--------------
e93f...55 | Order Shipped! | high     | 2025-04-22 13:00:00

delivery_logs
--------------------------------------------------------------
id        | notification_id | device_id | status     | attempt_count
----------+-----------------+-----------+------------+---------------
d95b...11 | e93f...55        | f7a9...91 | delivered  | 1

Mejores prácticas de gestión del token

• Tokens desduplicado: Múltiples dispositivos pueden enviar el mismo token (especialmente en Android); deduplicar en el registro.
• Manejo de expiración de tokens: Validen periódicamente tokens a través de servicios de retroalimentación (por ejemplo, retroalimentación de APN, errores no registrados de FCM) y marque inactivos.
• Eliminaciones suaves: Use banderas `IS_ACTIVE` en lugar de eliminaciones duras para evitar registros de entrega huérfanos.
• Índice sabiamente: Los dispositivos deben indexarse ​​en `(User_id, Plataforma)` y `(Token)` para búsqueda rápida y desduping.
• Evite los unidos al usuario en tiempo de ejecución: Mantenga todos los datos de orientación (tokens, opt-ins) en tiendas de acceso rápido como Redis o vistas pre-unidas para ejecuciones de entrega de alta velocidad.

Estrategias de múltiples tenientes y aislamiento

Si admite múltiples aplicaciones o clientes:

• Estrategia de columna del inquilino: Agregue una columna `inquil_id` a cada tabla y aplique el aislamiento de nivel de fila.
• Aislamiento de DB lógico: Use esquemas o bases de datos separadas por inquilino si SLA y la sensibilidad de los datos lo requieren.
• Separación de ruta de escritura: Aislar los mensajes transaccionales de alta prioridad de las colas a granel/marketing en la capa de DB para evitar problemas de vecinos ruidosos.

Partición y escala

A escala, ciertas tablas (como entrega_logs) crecerá rápidamente. Considerar:

• Partición basada en el tiempo: Registros de fragmentos mensuales o semanales para evitar índices hinchados.
• Política de archivo: Mueva registros más antiguos al almacenamiento en frío (por ejemplo, S3 + Athena) para el acceso a la auditoría sin afectar el rendimiento en vivo.
• Caché de token: Sincrita los tokens de dispositivo activo en Redis o DynamodB para bucles de envío de alto rendimiento.

Esquema de caché de token redis

Redis se usa como una capa de búsqueda de token en memoria optimizada y optimizada. Evita presionar la base de datos primaria durante el envío de mensajes y admite búsquedas de tiempo constante en conjuntos de usuarios/dispositivos masivos.

Casos de uso primarios:

• Ventilador rápido de tokens de dispositivo por usuario
• Buscar por segmentos de usuario (por ejemplo, dispositivos iOS activos)
• Deduplicación de tokens y control de vencimiento
• Aplicación de TTL para tokens inactivos o rotados

Estructura clave recomendada

Key:     push:user::tokens
Type:    Redis Set
Value:   token::
TTL:     Optional (based on last_active)

Ejemplo:

Key:     push:user:5b6ed...d1:tokens
Value:  {
           "token:ios:abc123token...",
           "token:web:def456token...",
           "token:android:xyz789token..."
        }

Clave alternativa para la búsqueda de token directo

Key:     push:token::
Type:    Hash
Fields:  {
           user_id: ,
           app_version: ,
           last_seen: ,
           is_active: true/false
         }
TTL:     30 days from last_seen

Ejemplo:

Key:     push:token:ios:abc123token...
Value:  {
           user_id: "5b6ed...d1",
           app_version: "6.4.1",
           last_seen: "2025-04-21T18:11:45Z",
           is_active: true
        }

Mejores prácticas

• Carga a granel de DB: Los trabajos de calentamiento de caché deben sincronizar tokens activos del DB relacional en el inicio o mediante CDC (Cambiar la captura de datos).
• Invalidar en un registro: Cuando un dispositivo no está registrado o el token no está válido por APNS/FCM, elimine la entrada Redis.
• Mantenga TTL Lean: Los tokens que no se usan en 30-60 días deben expirar para evitar la hinchazón de la caché.
• Fanotación de nivel establecido: Use conjuntos de Redis para obtener todos los tokens por usuario y realizar el ventilador de mensajes de manera eficiente en los procesos de trabajadores.
• Soporte de múltiples inquilinos: Prefijo todas las claves con ID de inquilino si funciona en un entorno de múltiples inquilinos.

Este caché complementa la capa de DB persistente al servir como nivel de búsqueda de baja latencia durante el bucle de envío crítico. También ayuda a los flujos de entrega de segmentos (por ejemplo, solo a enviar a los usuarios con tokens iOS activos) sin costosas uniones relacionales o escaneos completos.

Diseño de componentes detallados

Cada parte del sistema tiene su propia responsabilidad, pero la forma en que trabajan juntas define si su arquitectura push puede escalar o desmoronarse. En esta sección, desglosaremos la capa de componentes centrales por capa: manejo de datos, lógica de servicio, trabajadores de entrega y ganchos de interfaz de usuario opcionales.

1. Capa de datos (almacenamiento, acceso y almacenamiento en caché)

• DB relacional: Almacena entidades centrales (usuarios, dispositivos, preferencias, notificaciones, registros de entrega).
• Redis: Sirve como una capa de búsqueda de alta velocidad para tokens activos, entregas recientes y reglas de supresión en tiempo real.
• ORM o capa de acceso de datos: Use una abstracción limpia para hacer cumplir la validación, los valores predeterminados de campo y las restricciones de esquema. Evite escribir SQL crudo en bucles de entrega.
• Lea el uso de réplica: Enriquezca consultas de lectura de alto volumen (por ejemplo, búsqueda de ventilador) a las réplicas para evitar la contención de escritura.

2. Capa de aplicación (enrutamiento, filtrado, segmentación)

La capa de aplicación es el cerebro del sistema. Sabe qué enviar, a quién, cuándo y bajo qué condiciones. Aquí es donde vive la lógica de negocios.

• API de ingestión: Maneja las solicitudes entrantes de los servicios internos (OTP, herramientas de marketing, desencadenantes transaccionales).
• Servicio de enrutamiento de mensajes: Decide qué usuarios/dispositivos deberían recibir qué mensaje. Se une a los metadatos de mensajes con conjuntos de tokens Redis.
• Motor de preferencias y reglas: Aplente de opción/salida, límites de canal (por ejemplo, pings de marketing Max 2 por día) y ventanas de tiempo (por ejemplo, sin mensajes a las 2 a.m.).
• Controlador de velocidad: Despacho de mensajes de estrangulamiento por inquilino, por plataforma, por región. Se integra con contadores de Redis o algoritmos de ventana deslizante.

3. Capa de integración (Servicios de entrega y trabajadores)

Cada plataforma (APNS, FCM, WebPush) tiene sus peculiaridades, así que no las resumas detrás de una interfaz genérica. En cambio, trátalos como ciudadanos de primera clase con servicios de entrega dedicados.

• Trabajador de APN: Utiliza autenticación basada en token a través de JWT. Maneja empuje sobre http/2. Administra el grupo de conexión TCP y los límites de velocidad de Apple.
• FCM Worker: Auth a través de cuentas de servicio. Mensajes de lotes por tema o grupo de usuarios. Rastrea los errores por servicio (por ejemplo, no registrado, cuota excedida).
• WebPush Worker: Implementa VAPID, cifra las cargas útiles utilizando la criptografía de la curva elíptica y envía directamente a URI de punto final.
• Reintento de la cola: Cualquier entrega fallida se vuelve a colocar con un retroceso exponencial. Los DLQ (colas de letras muertas) capturan fallas persistentes para la inspección.

4. Capa de interfaz de usuario (opcional, orientada al administrador)

No todos los sistemas necesitan esto, pero para las operaciones de marketing internas o los equipos de productos, un tablero liviano puede ser útil.

• Compositor de campaña: Crear y programar explosiones de notificación a segmentos de usuario con herramientas WYSIWYG.
• Vista previa y orientación: Prueba en vivo en dispositivos de prueba o cubos A/B antes de un lanzamiento completo.
• Auditoría de actividad: Panel de control en tiempo real que muestra lo que hay en la cola, lo que se entrega y lo que falló (con códigos de razón).

Consejos de diseño

• Romper a cada trabajador en microservicios sin estado que puedan escalar horizontalmente.
• No reutilice el mismo servicio para la entrega y la retroalimentación (por ejemplo, recibos de APNS). Aislar esos flujos para la resiliencia.
• Agregue ID de registro estructurado y correlación en cada capa para la trazabilidad.

Consideraciones de escalabilidad

Los sistemas de notificación push no solo necesitan funcionar, sino que necesitan trabajar *rápido *y *a escala *, bajo sobretensiones de tráfico impredecibles. Esta sección describe los patrones, las estrategias de infraestructura y las salvaguardas necesarias para mantener el rendimiento alto y las latencias bajas, incluso cuando envía millones de mensajes por minuto.

Escala horizontal a través de niveles

Cada componente en el sistema (API de inicio, enrutador, trabajadores, colas) debe ser horizontalmente escalable. Esto permite un ajuste independiente de los cuellos de botella sin proporcionar demasiado toda la tubería.

• Puertas de enlace / entrada de la API: Las API frontales deben automáticas basadas en CPU/RPS. Use la limitación de la tasa para proteger los servicios posteriores.
• Trabajadores sin estado: Los trabajadores de entrega y los enrutadores deben ser apátridas y contenedores. Use Kubernetes HPA (POD Horizontal AutoScaler) o reglas de autoscalización de Fargate basadas en la profundidad de la cola, CPU o latencia.
• Escala basada en la profundidad de la cola: Rastree el tamaño del retraso y genere más trabajadores cuando la profundidad cruza el umbral (por ejemplo, kafka lag o la longitud de la cola de conejos).

Fragmentación y partición

• Fragmento por usuario_id: Cargas de trabajo de entrega de partición por ID de usuario hash para preservar la localidad y evitar la contención en DB o caché de tokens.
• Partición de Kafka: Use claves de mensaje basadas en la ID de usuario o inquilino para enrutar notificaciones al fragmento de grupo de consumo correcto.
• Partición de la base de datos: Para mesas grandes como entrega_logs, use la partición basada en el tiempo (por ejemplo, mensualmente) para mantener la velocidad de consulta.

Optimizaciones de rendimiento de ventilador

El cuello de botella real en los sistemas de alta escala es ventilador: mapeo de un mensaje lógico a miles o millones de tokens de dispositivos.

• Redis Set Union: Use Redis para obtener todos los tokens para un usuario o cohorte instantáneamente utilizando operaciones establecidas.
• Llama de API por lotes: Mensajes de grupo por plataforma y envío por lotes (por ejemplo, FCM admite hasta 500 tokens por solicitud por lotes).
• Deduplicación del token: Asegúrese de que no hay tokens duplicados en colas de entrega. Mantener la singularidad a través de Redis o paso de preprocesamiento.

Estrategia de almacenamiento en caché

• Tokens: Almacenado en caché por identificación de usuario. TTL se actualizó en la entrega o el inicio de sesión.
• Preferencias: Reglas de supresión de caché (por ejemplo, horas tranquilas, tapas de frecuencia) en Redis o tienda local de memoria.
• Estrangulamiento: Redis Counters (incry + TTL) o cubos de token para CAP a nivel de inquilino y globales.

Patrones de resiliencia

• Aislamiento de mamparo: Piscinas de trabajadores separadas por plataforma. Una desaceleración de FCM no debe bloquear los envíos de APNS.
• Colas de letras muertas: Los mensajes de falla persistentemente (por ejemplo, tokens no válidos) se descargan e registran para inspección sin detener los flujos de entrega.
• Circuiters: Deje de reintentar temporalmente a los proveedores posteriores que muestran altas tasas de falla (por ejemplo, APNS 503).
• Estrategias de retroceso: Use el retroceso exponencial con Jitter para las colas de reintento. Evite Stampedes durante el estrangulamiento del proveedor.

Puntos de referencia de rendimiento (objetivos de línea de base)

• Ingestión de API: 2,000–10,000 RP por nodo dependiendo del tamaño de la carga útil.
• Enrutamiento y ventilador: 5,000–20,000 Búsquedas de token de dispositivo/seg con partición Redis +.
• Rendimiento del trabajador de entrega:
  
  • APNS: ~ 5,000–10,000 empujes/min por conexión (http/2 multiplexado)
  • FCM: ~ 12,000/min con solicitudes por lotes
  • WebPush: ~ 2,000/min (envía un punto final único)

Arquitectura de seguridad

Push Notification Systems Interface con datos confidenciales del usuario, plataformas de mensajería en la nube y servicios internos. Si la seguridad no se hornea en cada capa, desde el almacenamiento de tokens hasta las interacciones API, se está configurando para fugas de privacidad, vectores de abuso y fallas de cumplimiento. Esta sección cubre los principios y prácticas de diseño de seguridad esencial para endurecer su sistema de extremo a extremo.

1. Autenticación y autorización

• Control de acceso interno: Todas las API internas (ingestión, programación, enrutamiento) deben protegerse con JWTS de corta duración o TLS mutuos, especialmente si es accesible en todos los servicios o entornos.
• Políticas de API Gateway: Use IAM o RBAC de nivel Gateway para restringir qué servicios o usuarios pueden enviar diferentes tipos de notificaciones (por ejemplo, transaccional versus marketing).
• Separación del inquilino: Si admite sistemas de múltiples inquilinos, aplique un estricto aislamiento basado en inquilinos en cada consulta, ruta y flujo de envío de mensajes.

2. Gestión de credenciales de plataforma

Las integraciones de terceros con APN y FCM requieren secretos que deben manejarse con cuidado.

• Tienda las claves en un gerente secreto: Use herramientas como AWS Secrets Manager, Hashicorp Vault o GCP Gerente secreto para almacenar las claves APNS y las credenciales FCM.
• Gire las credenciales periódicamente: Construya la automatización para rotar las credenciales de servicio al menos trimestralmente.
• Límite de la llave de la llave: Use cuentas de servicio con los menores privilegios requeridos, nada más, nada menos.

3. Seguridad de carga útil

• No incluya PII en cargas útiles: Las cargas útiles a menudo son visibles en el nivel del sistema operativo (especialmente Android). Nunca incluya nombres, direcciones de correo electrónico o tokens confidenciales.
• Cifrar en reposo y en tránsito: Todos los datos en la base de datos y REDIS deben estar encriptados utilizando AES-256 o cifrado AT-REST específico de la plataforma.
• Cifrado de carga útil web: Cifrado: Web Push basado en VAPID requiere cifrado de curva elíptica (NIST P-256); Esto debe manejarse adecuadamente para evitar fallas de entrega silenciosa.

4. Protección por abuso y limitación de tasas

Left sin control, se puede armarse un sistema de empuje, ya sea para usuarios de spam o para sobrecargar la infraestructura de entrega.

• Límites de velocidad por servicio: Use contadores Redis o algoritmos de bucket con fugas para hacer cumplir los límites de velocidad por-API y por inquilino.
• Control de cuotas: Los límites diarios de mensajes por usuario o segmento (especialmente para marketing) deben aplicarse en la capa de enrutamiento.
• Pistas de auditoría de nivel de autenticación: Todas las solicitudes para enviar mensajes deben ser auditables con el nombre del servicio, la identidad del usuario, la IP y los metadatos del mensaje.

5. Secretos e higiene de credenciales

• Utilice el aislamiento a nivel de entorno: Nunca comparta credenciales de desarrollo, puesta en escena y productos para los servicios push.
• Deshabilitar registros de texto sin formato: Evite registrar tokens, credenciales o presionar cargas útiles con metadatos confidenciales en registros. Enmascarar todo lo que no sea necesario para la depuración.
• Monitoreo del mal uso: Alerta si el uso se extiende fuera de los patrones esperados, especialmente de alto volumen, envía desde cuentas no productivas o errores repentinos de FCM.

6. Protecciones del lado del cliente (mínimo pero vale la pena mencionar)

• Rotación de token de nivel de aplicaciones: Asegúrese de que su SDK móvil actualice los tokens periódicamente y los desanime en el inicio de sesión o desinstalado.
• SSL fijación (opcional): Si la aplicación se conecta a su backend directamente para registrarse para impulsar, considere la fijación para evitar ataques MITM.

Extensibilidad y mantenibilidad

Un sistema de empuje escalable no es una construcción única: debe evolucionar con las necesidades comerciales cambiantes, las actualizaciones de la plataforma y los patrones de uso. La arquitectura debe ser modular, fácil de extender y segura de mantener sin introducir regresiones. Esta sección describe cómo estructurar su infraestructura push para la evolución a largo plazo y la cordura del desarrollador.

1. Arquitectura amigable para los complementos

Una separación limpia entre la lógica del núcleo y la lógica específica de la entrega permite la iteración más rápida sin desestabilizar los flujos de producción.

• Trabajadores de entrega como complementos: Encapsulate APN, FCM y WebPush Logic en módulos independientes con una interfaz de entrega compartida (por ejemplo, `Enviar (token, carga útil, configuración)`).
• Transformadores de mensajes: Implementar ganchos de transformación por plataforma (por ejemplo, APNS usa `alerta`, FCM usa` notificación` + `data`).
• Ganchos para la lógica personalizada: Permitir ganchos previos y posteriores a la entrega en la capa de enrutamiento para anulaciones específicas del inquilino, por ejemplo, aceleración personalizada o lógica A/B.

2. Prácticas de código limpio

Las bases de código de empuje tienden a convertirse en terrenos de vertido de hacks específicos de la plataforma a menos que se mantenga rigurosamente.

• Contratos de interfaz estrictos: Use interfaces claras para los módulos de entrega y las definiciones de mensajes (por ejemplo, `MessagePayLoad`,` EntrewingContext`).
• Gestión de configuración central: Todos los límites de tarifa, políticas de reintento y credenciales de plataforma deben definirse externamente en archivos de configuración o administradores de secretos.
• Límites de servicio: Evite el acoplamiento de la lógica de enrutamiento con la lógica de entrega. Trate a cada uno como un microservicio desplegable independientemente.

3. Flagantes de características y versiones

Apoya el desarrollo de características iterativas y la compatibilidad con atraso a través de versiones estrictas.

• Formatos de mensaje versionados: Definir esquemas de mensajes con versiones (`v1`,` v2`, etc.) y admitir actualizaciones en paralelo sin romper los formatos más antiguos.
• Banderas de características para nuevos flujos: Lanza una nueva lógica de entrega detrás de las banderas por inquilino o entorno para minimizar el radio de explosión.
• Modelo de depresión suave: Marque las API heredadas y las estructuras de mensajes para la eliminación programada; Agregue registro cuando se use.

4. Capas de prueba y validación

Una carga útil rota puede cascade en fallas de entrega. Salvaguardar cada nuevo lanzamiento con una fuerte validación.

• Validación de esquema: Use el esquema JSON o la validación de ProtoBuf antes de encarear mensajes para el envío.
• Prueba de contrato: Defina las expectativas de los módulos de plataforma utilizando PACT o herramientas similares para evitar la deriva de integración.
• Modo de sandbox: Proporcione un modo de prueba o prueba en seco para que los servicios internos simulen Push sin golpear puntos finales en vivo.

5. Mantenibilidad contra los paternos para evitar

• Comportamiento específico de la plataforma de codificación dura: Siempre resumir la lógica de la plataforma en módulos o complementos.
• Mezclar lógica de inquilinos con lógica global: Utilice servicios de alcance o condiciones a nivel de ruta: no se anule en línea de inquilinos.
• Falta de observabilidad en nuevos flujos: Las nuevas rutas o módulos deben incluir registros estructurados, métricas y manejo de errores desde el primer día.

Optimización del rendimiento

Empujar millones de notificaciones no se trata solo del diseño del sistema, sino que también se trata de cuán eficientemente se ejecuta cada componente bajo presión. El ajuste de rendimiento puede reducir la latencia, mejorar el rendimiento y evitar fallas aguas abajo. Esta sección se centra en cómo optimizar su tubería push en las capas de datos, procesamiento y entrega.

1. Ajuste de la consulta de la base de datos

• Índices dirigidos: Asegure los índices de `token`,` user_id` y `notification_id` en sus respectivas tablas. Los índices compuestos ayudan con las lecturas de ventilador (por ejemplo, `dispositivos_id, status`).
• Consulta por ID de segmento, no filtros de usuario sin procesar: Evite consultas complejas de unión durante el tiempo de envío. Segmentos de precomputas y ID de usuario de caché o tokens en Redis.
• Gestión del grupo de conexión: Use la agrupación de conexión (por ejemplo, PGBouncer) para evitar cuellos de botella de solicitud de punta durante las carreras de alto volumen.

2. Eficiencia de ventilador de token

• Lotes lotes de Redis: Al obtener tokens por usuario o per segmento, use siempre `smembers` +` mget` en lotes tuberculados.
• Bucles de entrega a granel: Proceso en lotes (por ejemplo, 500–1,000 tokens por iteración) para evitar la sobrecarga de la red por dispositivo.
• Copia de almacenamiento en caché de la plantilla de carga útil: Cache renderizó cargas útiles (título/cuerpo/metadatos) al transmitir a grupos de dispositivos similares.

3. Procesamiento y ajuste de trabajadores de async

• Mensaje Prefectado: Use los recuentos de mensajes previos a los mensajes (por ejemplo, Kafka `fetch.min.bytes`, RabbitMQ` prefetch_count`) para reducir el tiempo de inactividad en los trabajadores de entrega.
• Grupo de entrega: FCM y WebPush permiten cierto grado de lotes: use esto al enviar campañas no personalizadas.
• Agrupación de trabajadores por región: Ejecute grupos de trabajadores aislados (o POD) por región geográfica para minimizar la latencia de región transversal y reducir el costo de la salida de la nube.

4. Limitando y control de flujo de tasa

• Contadores de ventana deslizante: Use los scripts Redis Lua para implementar límites de velocidad a nivel de plataforma (por ejemplo, máximo de 100k/seg por plataforma o inquilino).
• Cola de cola: Reducir dinámicamente las tasas de lectura del mensaje del corredor cuando las tasas de error aumentan (por ejemplo, APNS 429s o errores de cuota FCM).
• Control de retroceso: En reintentos, use un retroceso exponencial nervioso para evitar que los rebaños tronados sean entregas fallidas.

5. Rendimiento de representación frontend (solo empuje web)

• Minimización de carga útil: Los mensajes de WebPush deben ser compactos: descarte metadatos adicionales, mantenga a ~ 2kb o menos para el renderizado más rápido.
• Enrutamiento en el clic: Use parámetros de consulta o enlaces profundos en WebPush `click_action` para conducir experiencias más rápidas en la aplicación o navegador.
• Enriquecimiento de renderizado perezoso: Siempre que sea posible, muestre contenido de notificación mínima y cargue detalles completos después de que el usuario haga clic.

6. Optimización de bucle de monitoreo y retroalimentación

• Panear los percentiles de latencia: No solo monitoree el tiempo de entrega promedio. Pista P90, P99 para atrapar la lentitud de entrega de cola larga.
• Filtrado de retroalimentación: Ingesta solo la retroalimentación crítica de entrega (token expirado, el dispositivo inalcanzable) en lugar de todo, para reducir la carga analítica.
• Agregación de métricas: Utilice herramientas como Prometeo con etiquetas conscientes de la cardinalidad para evitar la explosión métrica bajo un alto volumen.

Estrategia de prueba

Un sistema que empuja a millones de dispositivos no puede depender de QA manual o pruebas aisladas. La entrega es asíncrona, dependiente de terceros y en tiempo real, lo que significa que las pruebas deben estar en capas, automatizadas y resistentes a la falla. Esta sección cubre cómo abordar las pruebas en todas las fases: desarrollo local, tuberías de CI y endurecimiento de producción.

1. Prueba unitaria

Las pruebas unitarias aseguran que la lógica interna se comporte correctamente a través del enrutamiento, la resolución del token y la generación de carga útil.

• Lógica de enrutamiento de prueba: Validar los filtros de orientación de usuario, la aplicación de preferencias y la división de la plataforma.
• Conjuntos de token simulados: Simule las respuestas Redis/DB con asignaciones de token falsas para probar la lógica de ventilador.
• Validación de esquema: Asegúrese de que las cargas útiles se ajusten a los esquemas de la plataforma: estructura de alerta/mensajes, campos específicos de la plataforma, etc.

2. Pruebas de integración

• Colas de mensajes en memoria: Ejecute kafka/rabbitmq localmente (o use contenedores de prueba) para simular el flujo completo de productor a consumidor.
• Adaptadores de entrega falsos: APNS simulados, FCM y Webpush con puntos finales locales que simulan casos de éxito/falla, incluidos dispositivos estranguladores o no registrados.
• Flujo de entrega de extremo a extremo: Afirmar que un mensaje enviado a la API de Ingestión llega con éxito al adaptador de entrega simulada a través de la cola, el motor de reglas y los servicios de trabajadores.

3. Pruebas de contrato

Las pruebas de contrato validan que los módulos de entrega de la plataforma no se rompen debido a los cambios externos de formato de API o mensaje.

• Use PACT o herramientas similares: Defina las expectativas del contrato para cada módulo de entrega (APNS, FCM, WebPush).
• Esquemas versionados: Mantenga los formatos de mensaje versionados y verifique la compatibilidad con versiones anteriores en los cambios.

4. Pruebas de carga y estrés

Los sistemas de empuje deben sostenerse bajo volúmenes del mundo real. Las pruebas de carga ayudan a validar el rendimiento de la cola, los éxitos de Redis y la contención de DB.

• Simular campañas: Inyecte los mensajes de 10m+ en la cola para observar la escala de los trabajadores, las tasas de error y la latencia de mensajes.
• Pruebas de espiga y remojo: Valide cómo el sistema maneja ráfagas cortas (100k/min) frente al volumen estable a largo plazo (10k/seg durante horas).
• Aislar servicios lentos: Monitoree qué componentes (por ejemplo, enrutamiento, DB escribe, caché del token) se desaceleran bajo volumen.

5. Cobertura de tuberías de CI

• Pruebe cada ruta de empuje: Incluya la lógica de entrega, los reintentos de retroceso y el manejo de fallas como parte de las ejecuciones automatizadas de CI.
• Use tokens sintéticos: Genere tokens APNS/FCM de ficma para las cargas útiles de prueba (nunca use las reales en CI).
• Esquemas de pelusa: Validen automáticamente todas las cargas útiles contra las especificaciones de la plataforma antes de fusionarse utilizando el esquema JSON o las verificaciones de ProTobuf.

6. Caos e inyección de fallas (avanzado)

Para los equipos que operan a gran escala, introduzca el caos controlado para atrapar casos de borde antes que los usuarios.

• Agradecimientos de entrega de caída: Simule los retrasos o la pérdida de la red entre el trabajador y el proveedor de empuje.
• Inyectar cargas útiles malas: Corruptos en campos o violar los contratos de esquema para confirmar las capturas del sistema y aislan el problema.
• Ingestión de retroalimentación del acelerador: Retrasar los recibos de entrega para garantizar que el sistema no bloquee ni bloquee debido a las actualizaciones de estado faltantes.

DevOps y CI/CD

Los sistemas de notificación impulsados ​​abarcan múltiples servicios, colas, bases de datos e integraciones de terceros. Esa complejidad exige una tubería de DevOps automatizada y confiable que pueda construir, probar, implementar y revertir con confianza. Esta sección cubre las herramientas y las prácticas necesarias para mantener su tubería de entrega rápida, segura y observable.

1. Diseño de tubería CI/CD

• CI Pasantías: Lint → Pruebas unitarias → Pruebas de contrato → Pruebas de integración → Validación de esquema → Docker Build
• Etapas de CD: Despliegue canario → Verificaciones de salud → Puerta de métricas → Desmero completo
• Esquema previo a la implementación Diff: Migraciones de bases de datos automáticas para compatibilidad y posibles problemas de tiempo de inactividad (por ejemplo, agregando columnas no nulas sin valores predeterminados).

2. Estrategias de implementación

• Implementación de color verde azulado: Para servicios con estado como programadores o API de ingestión, use azul verde para cambiar el tráfico sin tiempo de inactividad.
• Implementación canaria: Para los trabajadores y enrutadores de entrega, despliegue en un pequeño subconjunto de vainas (por ejemplo, 5%) y observe las fallas de entrega o los errores de la API de la plataforma.
• Despliegos progresivos: Rolle las funciones utilizando banderas de configuración (no ramas de código) para que los cambios se puedan alternar en tiempo de ejecución.

3. Infraestructura como código (IAC)

• Use Terraform o Pulumi: Gestione la infra en AWS/GCP para colas, DBS, grupos Redis y VPC.
• Entornos dinámicos: Gire los entornos de prueba aislados en las ramas de características para probar los flujos de empuje de extremo a extremo sin la puesta en marcha contaminante.
• Automatización de secretos: Almacene las credenciales de servicio de empuje en gerentes secretos e inyecte en vainas a través de secretos o sidecars sellados.

4. GITOPS y Gestión de la configuración

• Configuraciones versionadas: Mantenga los límites de la velocidad, las políticas de reintento y las anulaciones de los inquilinos en GIT, no codificados en los servicios.
• Comportamiento configado: Inyectar configuraciones específicas de la plataforma en trabajadores (por ejemplo, tamaño del grupo APNS, WebPush TTL) a través de Kubernetes configMaps.
• Reversión a través de Git Revert: Si una configuración o un indicador rompe la producción, GITOPS permite una reversión rápida con auditabilidad.

5. Validación de liberación y cheques posteriores a la implementación

• Ganchos posteriores a la implementación: Activar las controles de salud o las pruebas de humo automáticamente después del lanzamiento.
• Métricas de entrega de relojes: Monitoree las tasas de entrega, los códigos de error y el tamaño de la cola en los 15-30 minutos después del despliegue antes de escalar completamente.
• Comportamiento de Falla rápido: Si los errores de entrega aumentan (por ejemplo, tokens inválidos, 403 de FCM), despliegue de auto-halt y notifican de guardia.

Monitoreo y observabilidad

Los sistemas de notificación push son asíncronos, distribuidos y dependen de servicios de terceros de caja negra como APN y FCM. Sin una observabilidad adecuada, las fallas pasan desapercibidas, se producen caídas de entrega silenciosas y la depuración se convierte en conjeturas. Esta sección describe qué monitorear, cómo rastrear el flujo de mensajes y cómo construir alertas significativas.

1. Registros

• Registro estructurado: Use registros JSON con campos como `Message_id`,` Device_id`, `Platform`,` Status` y `Error_code` para cada etapa de entrega.
• IDS de correlación: Registros de etiquetas desde la ingestión → Enrutamiento → trabajadores de entrega con una ID de solicitud compartida de trazabilidad de extremo a extremo.
• Redactos campos sensibles: Tokens de máscara, ID de usuario o contenido de carga útil en registros, especialmente en plataformas compartidas o de terceros.

2. Métricas

Las métricas te dicen lo que está sucediendo a nivel macro. Agreguelos a través de los servicios para detectar problemas en toda la plataforma temprano.

• Rendimiento de entrega: Mensajes enviados por plataforma, por minuto. Desglose por `inquilino`,` priority` y `message_type` (transaccional/marketing).
• Tasa de éxito/error de entrega: Los seguidores `Entreñados`,` Dropped`, `fallado ‘y` Retintying` cubos, con etiquetas para causa raíz (`no registrado`,` tasa_limited`, `invalid_token`).
• Latencia de la cola: Tiempo desde la enqueue hasta la recolección de trabajadores y el trabajador y el reconocimiento de la plataforma.

3. Rastreo

Las trazas son críticas cuando los mensajes se desvanecen en silencio o se retrasan. Integre el rastreo distribuido en cada servicio interno.

• Tramos de rastreo: Ingestión → Redis/token Búsqueda → Verificación de preferencias → Enqueue de cola → Trabajador de envío → Entrega de plataforma.
• Registros de enlace a trazas: Incluya ID de rastreo en registros y enlaces de tablero (por ejemplo, desde Kibana hasta Jaeger/Tempo).
• Control de la velocidad de muestreo: Siempre traza OTP y mensajes fallidos; Use un muestreo probabilístico para campañas para reducir la sobrecarga.

4. Paneles

Los paneles en tiempo real ayudan a los operadores e ingenieros de guardia a comprender la salud del sistema de un vistazo.

• Estado de entrega de la plataforma: Cuentas en tiempo real de mensajes enviados, fallidos y reintentos por plataforma (APNS/FCM/WebPush).
• Profundidad de la cola: Visibilidad en vivo en las colas de enrutamiento y entrega: la profundidad de la cola aumentada indica saturación o desaceleración aguas abajo.
• Análisis de señal de retroalimentación: Visualice las invalidaciones de tokens, los límites de velocidad golpean y los recibos de retroalimentación de las plataformas push.

5. Alerta

• Alertas de pico de falla: Si los mensajes fallidos exceden un umbral (recuento absoluto o %de tasa de error) dentro de una ventana deslizante.
• Alertas de latencia de entrega: Si la latencia P95 excede SLA (por ejemplo, OTP> 3S, Campaña> 30s).
• Crecimiento de la cola de letras muertas: Alerta si los DLQ comienzan a acumular mensajes: señala una ruta de falla persistente.

6. Monitoreo de bucle de retroalimentación

Las plataformas como APNS y FCM envían comentarios de forma asincrónica. Estos recibos necesitan su propia tubería.

• Trabajadores de la ingestión de retroalimentación: Consumir y almacenar eventos de token no registrados, errores de entrega y avisos de límite de tarifas.
• Extracción de métricas: Las señales de retroalimentación agregan en paneles y distribuciones de clase de error.
• Automatización de limpieza de tokens: Activar trabajos de fondo para desactivar o eliminar tokens rancios según la retroalimentación de la plataforma.

Compensaciones y decisiones de diseño

Cada opción arquitectónica viene con compensaciones. Diseñar un sistema de notificación push escalable significa equilibrar constantemente la latencia versus rendimiento, simplicidad versus flexibilidad y confiabilidad frente a costo. Esta sección describe algunas de las decisiones clave tomadas en todo el sistema y las alternativas que se consideraron.

1. Trabajadores específicos de la plataforma versus interfaz de entrega unificada

• Decisión: Separe APN, FCM y WebPush en servicios de entrega aislados.
• Compensación: Más código y complejidad de implementación, pero aislamiento de fallas mucho mejor, ajuste de escalabilidad y capacidad de depuración por plataforma.
• Alternativa: Una interfaz unificada genérica podría reducir la duplicación de código, pero requeriría una lógica condicional extensa y reduciría la observabilidad.

2. Redis Token Cache vs. entrega de DB solo

• Decisión: Use Redis para la búsqueda de token activo y el ventilador durante el enrutamiento de mensajes.
• Compensación: Requiere sincronización de fondo y lógica de invalidación, pero mejora drásticamente el rendimiento de la entrega y reduce la carga de DB.
• Alternativa: Las lecturas de DB directas durante el abanico simplificarían la arquitectura, pero no escalarían en volúmenes a nivel de campaña.

3. Kafka para colas de mensajes versus colas más simples

• Decisión: Use kafka o registro distribuido equivalente para colas de enrutamiento y entrega.
• Compensación: Curva de aprendizaje más pronunciada y carga de gestión de infra, pero permite una alta durabilidad, reintentos y escalabilidad del consumidor.
• Alternativa: RabbitMQ/SQS es más fácil de operar, pero ofrecen menos flexibilidad para las garantías de abanico o entrega a gran escala.

4. Letras muertas colas vs. bucles de reintento en línea

• Decisión: Use DLQ dedicados para fallas permanentes y limite los requisitos en el lugar a 2–3 intentos.
• Compensación: Overos en operación ligeramente más alto, pero evita el bloqueo de la cola y permite el procesamiento de recuperación de asíncrono.
• Alternativa: El reintento en línea con el retroceso es más fácil de implementar, pero corre el riesgo de sobrecargar sistemas posteriores o retrasar mensajes.

5. Partición de DB basada en el tiempo versus crecimiento de tabla plana

• Decisión: Partition Delivery registra por mes para controlar el tamaño del índice y las políticas de retención.
• Compensación: Enrutamiento de consultas más complicado y fragmentación potencial de acceso a datos.
• Alternativa: Una mesa monolítica sería más fácil de manejar inicialmente, pero degradaría el rendimiento y complicaría la limpieza de retención.

6. Comprimensiones en la velocidad de características frente a las garantías de entrega

• Decisión: Separan transaccionales de los flujos de marketing en cada capa: ingestión, colas, servicios de entrega.
• Compensación: Más complejidad de enrutamiento e infraestructura adicional, pero evita que el tráfico no crítico degrade las rutas críticas (por ejemplo, OTP).
• Alternativa: Un flujo unificado simplifica el enrutamiento, pero arriesga el impacto del cliente durante las pesadas cargas de campaña o los estranguladores de la plataforma.

7. Áreas de deuda técnica conocidas

• Limpieza de tokens rancio: Necesita optimización o automatización a través de la ingestión de bucle de retroalimentación.
• Segmento pre-materialización: Actualmente se ejecuta justo en el tiempo durante el envío de campaña; debe moverse a trabajos de fondo.
• Escala de limitador de velocidad: Las instancias de Redis compartidas para el control de tarifas podrían convertirse en un cuello de botella bajo campañas a escala global.

Lo que esta arquitectura hace bien

Diseñar un sistema de notificación push escalable no se trata solo de enviar mensajes, sino que se trata de entregar los mensajes correctos, a los dispositivos correctos, de manera confiable y a escala. Esta arquitectura está diseñada especialmente para cumplir con ese desafío de frente, equilibrio de rendimiento, control y mantenimiento en un sistema altamente distribuido.

Control de llave

• Arquitectura desacoplada: La ingestión, el enrutamiento y la entrega se separan limpiamente para la resiliencia y la escalabilidad.
• Aislamiento de la plataforma: Cada servicio de empuje (APNS, FCM, WebPush) es manejado por un trabajador dedicado ajustado a sus peculiaridades.
• Token en caché y ventilador: Redis potencia la resolución de token rápido, lo que permite la entrega de mensajes de alto rendimiento sin marcar su DB principal.
• Durabilidad de datos: Las colas de mensajes aseguran una entrega confiable incluso cuando las API de la plataforma fallan, con DLQ que capturan casos de borde para una inspección posterior.
• Observabilidad en todas partes: El rastreo, las métricas y los registros estructurados hacen que las tuberías de entrega de depuración y los flujos a nivel de usuario sean prácticos a escala.
• Extensibilidad segura de funciones: Los componentes modulares, la lógica basada en gancho y el versiones de esquema permiten que el sistema evolucione sin romper las rutas heredadas.

Oportunidades para la mejora futura

• Estrucias de grano fino: Los límites de velocidad por usuario o por dispositivo podrían reducir aún más la nootificación y mejorar UX.
• Tubería de materialización del segmento: La segmentación de la descarga de los trabajos de antecedentes previamente programados haría que los lanzamientos de campaña sean aún más rápido.
• Optimización de entrega regional: Los trabajadores de entrega geo-locales podrían reducir la latencia y el costo de la salida en la nube al mantener las llamadas de la plataforma más cerca del origen del usuario.

Este sistema no solo funcionará, se mantendrá bajo presión, escala con crecimiento y se mantendrá mantenible a medida que evolucionen los casos de uso. Eso es lo que separa los scripts de notificación desechables de una plataforma de entrega de grado de producción en tiempo real.