Architekturhinweis: Wann man SQS FIFO anstelle einer DB-Warteschlange wählen sollte
Ein Entscheidungsrahmen, den ich verwende, wenn das Team standardmäßig auf eine von Postgres unterstützte Warteschlange zurückgreift.
Teil von Backend Craft
Teams greifen öfter auf "benutze einfach eine Tabelle"-Queues zurück, als sie sollten. Manchmal ist das richtig. Oft ist es eine Zeitbombe.
Mein Entscheidungsbaum:
- Ist eine Sortierung pro Schlüssel erforderlich? → SQS FIFO mit MessageGroupId. Eine DB-Queue bekommt das nur hin, wenn du vorsichtig mit
SELECT FOR UPDATE SKIP LOCKEDumgehst. - Wird der Durchsatz jemals ein paar hundert pro Sekunde überschreiten? → SQS. DB-Queues kämpfen mit dem Rest deiner App um Verbindungen und Zeilenlocks.
- Ist genau einmal beim Verbraucher erforderlich? → Keines von beiden bietet dir das. Entwerfe idempotente Verbraucher; nutze das Dedup-Fenster von SQS FIFO als Sicherheitsnetz.
- Befindet sich der Verbraucher außerhalb des Explosionsradius der DB? → SQS. Koppel einen externen Worker nicht an dein primäres Postgres.
Eine DB-Queue ist richtig, wenn die Arbeit intrinsisch an eine Transaktion gebunden ist — "nachdem diese Zeile bestätigt wurde, mache X." SQS ist richtig, wenn die Arbeit extrinsisch ist.
Verwandt
Weiterlesen
Tägliche Notiz: TIL — Polly SSML <mark> Tags
Polly's SSML <mark>-Tags geben Timing-Events über den Stream aus. Nützlich, um Bildschirmunterschriften mit der Sprachwiedergabe zu synchronisieren.
Sprachintegrationen auf Basis von asynchronen Chatbots entwickeln
Was passiert, wenn du einen asynchronen Chatbot mit Amazon Connect und Lex kombinierst, und wie kannst du Latenz, Barge-In und den Kontextübergang im Griff behalten?
Was ich beim Entwerfen von Omnichannel-Backend-Integrationen gelernt habe
Geteiltes Intent-Schema, letztlich konsistenter Gesprächszustand und warum der Kanal das Letzte sein sollte, was dein Backend darüber weiß.
Weiter geht's
Wohin als Nächstes?
Stöbere durch weitere technische Texte, sieh dir die Engineering Case Studies an oder melde dich direkt.