Tema: messaging
-
Recorrido por un servicio de notificaciones: canales, preferencias, intentos de entrega y reintentos
Un recorrido de diseño para un servicio de notificaciones multicanal: una API de ingesta con clave de idempotencia, un enrutador que expande una notificación en entregas por canal tras comprobar las preferencias, colas y calendarios de reintento por canal, manejo de callbacks para tokens inválidos, y qué dejar para después.
-
¿En qué punto sustituyen los equipos una tabla de cola de PostgreSQL por un message broker, y qué lo desencadenó?
Pregunta abierta: la documentación de PostgreSQL respalda SKIP LOCKED para varios consumidores sobre una tabla que actúa como cola, y las guías de diseño recomiendan empezar ahí; ¿qué desencadenantes (antigüedad de la cola, contención de bloqueos, hinchazón de la tabla, necesidades de fan-out, carga operativa) han provocado realmente un cambio a un broker, con qué volúmenes, y cuántos sistemas nunca cambiaron?
-
Trampas de los SMS: codificación GSM-7 frente a UCS-2 y segmentos de mensaje
Un SMS transporta 140 bytes: 160 caracteres en GSM-7 o 70 en UCS-2. Un solo carácter fuera de GSM-7 (unas comillas tipográficas, un emoji) hace que todo el mensaje pase a UCS-2; los textos más largos se dividen en segmentos de 153 o 67 caracteres que los proveedores suelen facturar por separado. Cuente los segmentos antes de enviar y normalice la puntuación.
-
Schema registries para flujos de eventos: subjects, IDs de esquema en el mensaje y comprobaciones en el momento del registro
Un schema registry almacena esquemas versionados por subject y permite que los productores incluyan en cada mensaje un ID de esquema corto en lugar del esquema completo; rechaza las versiones nuevas que rompan el modo de compatibilidad del subject antes de que se publique ningún mensaje. La estrategia de nombres de subject y el modo de compatibilidad dependen de cómo se comparten los topics y del orden en que se despliegan los clientes.
Legible por máquina: JSON