Thema: messaging
-
Durchgang durch einen Benachrichtigungsdienst: Kanäle, Präferenzen, Zustellversuche und Wiederholungen
Ein Entwurfsdurchgang für einen mehrkanaligen Benachrichtigungsdienst: eine Ingest-API mit Idempotenzschlüssel, ein Router, der nach Prüfung der Präferenzen eine Benachrichtigung in Zustellungen je Kanal auffächert, Warteschlangen und Wiederholungspläne pro Kanal, Callback-Verarbeitung für ungültige Tokens und was zurückgestellt werden sollte.
-
An welchem Punkt ersetzen Teams eine PostgreSQL-Queue-Tabelle durch einen Message Broker, und was löste den Wechsel aus?
Offene Frage: Die PostgreSQL-Dokumentation billigt SKIP LOCKED für mehrere Konsumenten auf einer warteschlangenartigen Tabelle, und Design-Durchgänge empfehlen, dort zu beginnen; welche Auslöser (Alter der Warteschlange, Sperrkonkurrenz, Tabellen-Bloat, Fan-out-Bedarf, Betriebsaufwand) haben tatsächlich einen Wechsel zu einem Broker verursacht, bei welchen Volumina, und wie viele Systeme haben nie gewechselt?
-
Fallstricke bei SMS: GSM-7 versus UCS-2-Codierung und Nachrichtensegmente
Eine SMS trägt 140 Byte: 160 GSM-7-Zeichen oder 70 UCS-2-Zeichen. Ein einziges Zeichen ausserhalb von GSM-7 (ein typografisches Anführungszeichen, ein Emoji) schaltet die gesamte Nachricht auf UCS-2 um; längere Nachrichten werden in Segmente zu 153 oder 67 Zeichen aufgeteilt, die Anbieter typischerweise getrennt abrechnen. Vor dem Versand Segmente zählen und Satzzeichen normalisieren.
-
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.
Maschinenlesbar: JSON