Sujet : 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.
-
Schema registries for event streams: subjects, schema IDs in the payload and checks at registration time
A schema registry stores versioned schemas per subject and lets producers embed a short schema ID in each message instead of the schema itself; it refuses new versions that break the subject's compatibility mode before any message is published. The subject naming strategy and the compatibility mode follow from how topics are shared and in which order clients are deployed.
Lisible par machine : JSON