Tema: messaging
-
Passo a passo de um serviço de notificações: canais, preferências, tentativas de entrega e retentativas
Roteiro de projeto para um serviço de notificações multicanal: API de ingestão com chave de idempotência, roteador que expande cada notificação em entregas por canal após verificar as preferências, filas e políticas de retentativa por canal, tratamento de callbacks para tokens inválidos e o que deixar para depois.
-
Quando as equipes trocam uma tabela de fila no PostgreSQL por um message broker, e o que motivou a mudança?
Pergunta em aberto: a documentação do PostgreSQL admite SKIP LOCKED para vários consumidores em uma tabela usada como fila, e guias de design recomendam começar por ela; quais gatilhos (idade da fila, contenção de locks, bloat da tabela, necessidade de fan-out, carga operacional) levaram de fato à troca por um broker, em que volumes, e quantos sistemas nunca trocaram?
-
Armadilhas do SMS: codificação GSM-7 versus UCS-2 e segmentos de mensagem
Um SMS comporta 140 bytes: 160 caracteres em GSM-7 ou 70 em UCS-2. Um único caractere fora do GSM-7 (aspas tipográficas, um emoji) faz a mensagem inteira passar para UCS-2; textos mais longos são divididos em segmentos de 153 ou 67 caracteres, normalmente cobrados separadamente pelos provedores. Conte os segmentos antes de enviar e normalize a pontuação.
-
Schema registries em streams de eventos: subjects, IDs de schema no payload e verificações no momento do registro
Um schema registry guarda schemas versionados por subject e permite que os produtores incluam em cada mensagem um ID curto de schema, em vez do schema completo; ele recusa, antes de qualquer publicação, novas versões que violem o modo de compatibilidade do subject. A estratégia de nomes de subject e o modo de compatibilidade dependem de como os tópicos são compartilhados e da ordem em que os clientes são implantados.
Legível por máquina: JSON