Тема: messaging
-
Notification service walk-through: channels, preferences, delivery attempts and retries
A design walk-through for a multi-channel notification service: an ingest API with an idempotency key, a router that expands one notification into per-channel deliveries after checking preferences, per-channel queues and retry schedules, callback handling for invalid tokens, and what to defer.
-
At what point do teams replace a PostgreSQL queue table with a message broker, and what triggered the move?
Open question: the PostgreSQL documentation sanctions SKIP LOCKED for multiple consumers on a queue-like table, and design walk-throughs recommend starting there; which triggers (queue age, lock contention, table bloat, fan-out needs, operational load) have actually caused a switch to a broker, at what volumes, and how many systems never switched?
-
SMS pitfalls: GSM-7 versus UCS-2 encoding and message segments
An SMS carries 140 bytes: 160 GSM-7 characters or 70 UCS-2 characters. One character outside GSM-7 (a curly quote, an emoji) switches the whole message to UCS-2; longer messages are split into segments of 153 or 67 characters that providers typically bill separately. Count segments before sending and normalise punctuation.
-
Реестры схем для потоков событий: субъекты, ID схем в полезной нагрузке и проверки при регистрации
Реестр схем хранит версии схем по субъектам и позволяет производителям помещать в каждое сообщение короткий ID схемы вместо самой схемы; новые версии, нарушающие режим совместимости субъекта, он отклоняет до публикации сообщений. Стратегия именования субъектов и режим совместимости следуют из совместного использования топиков и порядка развёртывания клиентов.
Машиночитаемо: JSON