Zuverlässige Hintergrundjob-Systeme mit BullMQ und Redis erstellen

Die Versendung einer Bestätigungs-E-Mail, die Erstellung eines Berichts, die Verarbeitung einer Zahlung – viele Aufgaben im Hintergrund müssen nicht abgeschlossen sein, bevor man auf einen Benutzer antwortet. Dieser Leitfaden zeigt, wie zuverlässige Systeme für Hintergrundaufgaben mithilfe von BullMQ in Kombination mit Redis erstellt werden können.

Stellen Sie sich einen Backend-Ansatz vor, bei dem fast jede Aufgabe direkt innerhalb des HTTP-Anfragenzyklus ausgeführt wird. Muss eine E-Mail gesendet werden? Das geschieht direkt dort. Muss ein PDF erstellt werden? Auch das direkt. Muss Daten im Hintergrund verarbeitet werden? Auch das inline.

Dieser Ansatz funktioniert anfangs gut. Dann hört er auf zu funktionieren.

Die API beginnt, langsamer zu werden. Anfragen laufen aus. Und wenn ein externer Dienst ausgefallen ist, kann die gesamte Anfrage zusammen mit ihm fehlschlagen.

Dann wird klar, warum Hintergrundaufgaben sinnvoll sind.

Anstatt die API dazu zu zwingen, jeden Schritt vor der Antwort abzuschließen, können Sie die Arbeit in eine Warteschlange legen und einen speziellen Worker damit beauftragen, sie separat zu bearbeiten.

Eine gute Option im Node.js-Ökosystem ist hierfür BullMQ, das durch Redis für die Speicherung unterstützt wird. So passen alle Komponenten zusammen.

1. Was ist eine Hintergrundaufgabe?

Eine Hintergrundaufgabe ist jede Arbeitseinheit, die nicht synchron im Rahmen einer HTTP-Anfrage ausgeführt werden muss.

Betrachten Sie einen typischen Registrierungsablauf. Wenn jemand ein Konto erstellt, muss die API möglicherweise Folgendes tun:

• Das Benutzerkonto anlegen
• Ein Willkommens-E-Mail versenden
• Ein Willkommens-PDF erstellen
• Eine Benachrichtigung senden
• Ein anderes nachgeschaltetes System aktualisieren

Man könnte versuchen, all das direkt vor der Antwort auszuführen:

Client
  ↓
API
  ↓
Create User
  ↓
Send Email
  ↓
Generate PDF
  ↓
Send Notification
  ↓
Response

Doch das zwingt den Benutzer dazu, auf die Fertigstellung aller Schritte zu warten.

Ein besserer Ansatz sieht so aus:

Client
  ↓
API
  ↓
Create User
  ↓
Add Job to Queue
  ↓
Response

Und getrennt davon:

Queue
  ↓
Worker
  ↓
Send Email
  ↓
Done

Weil die API nicht mehr jede Aufgabe vor dem Antworten abschließen muss, antwortet sie viel schneller.

2. Warum brauchen wir eine Warteschlange?

Nehmen wir an, das Versenden einer E-Mail dauert 1 Sekunde, die Erstellung eines PDFs 2 Sekunden und der Aufruf einer anderen API ebenfalls 1 Sekunde. Der Endpunkt könnte mehrere Sekunden lang blockiert bleiben, bevor er eine Antwort sendet – das ist eine schlechte Erfahrung für den Benutzer.

Noch schlimmer: Was passiert, wenn der E-Mail-Anbieter nicht erreichbar ist? Die Anfrage könnte fehlschlagen, obwohl die Erstellung des Benutzers tatsächlich erfolgreich war. Das ist eine unnötige Abhängigkeit zwischen zwei unzusammenhängenden Aufgaben.

Eine Warteschlange beseitigt diese Kopplung:

┌──────────────┐
                    │   Node API   │
                    └──────┬───────┘
                           ↓
                     Add Job
                           ↓
                    ┌──────────────┐
                    │    Redis     │
                    │    Queue     │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │    Worker    │
                    └──────┬───────┘
                           ↓
                Email / PDF / API / etc.

Durch diese Trennung haben die API und die Hintergrundaufgabe jeweils eine klare eigene Verantwortung.

3. Was ist BullMQ?

BullMQ ist eine Warteschlangenbibliothek für Node.js, die auf Redis angewiesen ist, um Aufgaben zu speichern und zu koordinieren. Ihre Architektur sieht auf höherer Ebene so aus:

Producer
   ↓
Queue
   ↓
Worker
   ↓
Job Processing

Der Producer ist dafür zuständig, Aufgaben zu erstellen. Die Warteschlange speichert sie. Der Worker verarbeitet sie tatsächlich.

Zum Beispiel:

await emailQueue.add("welcome-email", {
  userId: user.id,
  email: user.email
});

Im Grunde sagt die API Folgendes:

"Hier sind einige Aufgaben, die erledigt werden müssen."

Sie muss diese Aufgaben nicht selbst ausführen.

4. Erstellung einer Warteschlange

So sieht eine minimale BullMQ-Warteschlangeneinrichtung aus:

import { Queue } from "bullmq";

const connection = {
  host: "localhost",
  port: 6379
};const emailQueue = new Queue("email", {
  connection
});

Von dort aus können Sie Aufgaben hinzufügen:

await emailQueue.add("welcome-email", {
  userId: "123",
  email: "user@example.com"
});

Redis kümmert sich im Hintergrund um das Speichern aller mit der Warteschlange verbundenen Zustände. Konzeptionell kann man sich das so vorstellen:

email queue

Job 1
Job 2
Job 3
Job 4
Job 5

Der Worker nimmt anschließend diese Aufgaben in Angriff und verarbeitet sie.

5. Erstellen eines Workers

Der Worker ist der Teil, der tatsächlich die Arbeit ausführt:

import { Worker } from "bullmq";

const worker = new Worker(
  "email",
  async (job) => {
    console.log("Processing:", job.name);    await sendWelcomeEmail(
      job.data.email
    );
  },
  {
    connection
  }
);

Zusammengefasst sieht der Ablauf nun so aus:

API
 ↓
emailQueue.add()
 ↓
Redis
 ↓
Worker
 ↓
sendWelcomeEmail()

Die API muss nicht darauf warten, bis die E-Mail versandt ist – und das ist der wesentliche Vorteil von Hintergrundaufgaben.

6. Was passiert, wenn eine Aufgabe fehlschlägt?

Genau hier zeigt sich der eigentliche Vorteil einer Warteschlange gegenüber einem einfachen Serviceaufruf.

Bilden Sie sich folgende Konfiguration vor:

API
 ↓
Email Service
 ↓
ERROR

Wenn Sie eine API direkt aufrufen, müssen Sie sofort über einen Fehlschlag entscheiden.

Eine Warteschlange bietet eine weitere Option: Die Aufgabe kann einfach erneut versucht werden.

Hier ist ein Beispiel:

await emailQueue.add(
  "welcome-email",
  {
    email: "user@example.com"
  },
  {
    attempts: 3
  }
);

Mit dieser Konfiguration ist es dem Job gestattet, mehrere Versuche zu unternehmen, bevor er aufgibt.

Visuell sieht der Ablauf so aus:

Attempt 1
   ↓
Failed
   ↓
Attempt 2
   ↓
Failed
   ↓
Attempt 3
   ↓
Success

Dieses Muster ist äußerst wertvoll, wenn man mit unzuverlässigen Drittanbieterdiensten umgeht.

Allerdings sollten Wiederholungsversuche weder unbegrenzt noch nachlässig erfolgen.

Mit einer Konfiguration, bei der ein Job endlos ohne Grenzen weiter versucht, sollte man vorsichtig sein.

7. Wiederholungsversuche mit Verzögerung

Nehmen wir an, ein externer Dienst ist vorübergehend nicht verfügbar.

Was man vermeiden sollte, ist etwas wie folgt:

FAIL
RETRY IMMEDIATELY
FAIL
RETRY IMMEDIATELY
FAIL
RETRY IMMEDIATELY

Unmittelbare Wiederholungsversuche bei einem Problemdienst können die Situation tatsächlich verschlimmern.

Die Lösung besteht darin, zwischen den Versuchen eine Verzögerung einzufügen.

Zum Beispiel:

await emailQueue.add(
  "welcome-email",
  {
    email: "user@example.com"
  },
  {
    attempts: 5,
    backoff: {
      type: "exponential",
      delay: 5000
    }
  }
);

So sieht das konzeptionell aus:

Attempt 1 → Fail
       ↓
     5 sec
       ↓
Attempt 2 → Fail
       ↓
    10 sec
       ↓
Attempt 3 → Fail
       ↓
    20 sec
       ↓
Attempt 4 → Success

Die genaue Zeitgestaltung hängt davon ab, wie man die Strategie für Wiederholungsversuche und Verzögerungen konfiguriert.

Aber die zugrundeliegende Idee bleibt dieselbe:

Geben Sie vorübergehenden Fehlern Zeit zur Erholung, bevor Sie es erneut versuchen.

8. Verschobene Aufgaben

Nicht jede Aufgabe muss unmittelbar nach ihrer Erstellung ausgeführt werden.

Zum Beispiel:

Senden Sie eine Erinnerung 24 Stunden nach der Anmeldung.

BullMQ ermöglicht es Ihnen, eine Aufgabe für einen späteren Zeitpunkt zu planen.

await emailQueue.add(
  "reminder",
  {
    userId: "123"
  },
  {
    delay: 24 * 60 * 60 * 1000
  }
);

Konzeptionell:

Create Job
    ↓
Wait 24 hours
    ↓
Worker processes job

Dieses Muster tritt in Situationen wie folgenden auf:

• Erinnerungse-Mails
• Geplante Benachrichtigungen
• Ablauf der Testphase
• Zahlungserinnerungen
• Nachfollgemeldungen

9. Mehrere Arbeiterprozesse

Stellen Sie sich nun ein System vor, das pro Minute Tausende von Aufgaben erhält.

Ein einziger Arbeiterprozess kommt möglicherweise nicht mit.

Sie können die Leistungskapazität erhöhen, indem Sie mehrere Arbeiterprozesse gleichzeitig ausführen:

Redis Queue
                     ↓
          ┌──────────┼──────────┐
          ↓          ↓          ↓
       Worker 1   Worker 2   Worker 3
          ↓          ↓          ↓
        Jobs       Jobs       Jobs

Jeder zieht unabhängig Aufgaben aus der Warteschlange ab.

Zum Beispiel:

1000 email jobs

Man könnte etwas wie Folgendes sehen:

Worker 1 → Job 1, 4, 7...
Worker 2 → Job 2, 5, 8...
Worker 3 → Job 3, 6, 9...

Die Hinzufügung weiterer Worker ist eine Möglichkeit, die Durchsatzrate zu erhöhen.

Aber seien Sie vorsichtig:

Die Einführung weiterer Worker löst das Problem nicht automatisch.

Ihre Datenbank, Ihr E-Mail-Anbieter, Ihre CPU, Ihr Arbeitsspeicher sowie alle nachgelagerten Dienste haben jeweils ihre eigenen Kapazitätsgrenzen.

10. Konkurrenz

Neben dem Ausführen mehrerer Worker-Prozesse ermöglicht BullMQ es Ihnen auch, festzulegen, wie viele Aufgaben ein einzelner Worker gleichzeitig bearbeiten darf.

Zum Beispiel:

const worker = new Worker(
  "email",
  async (job) => {
    await sendEmail(job.data.email);
  },
  {
    connection,
    concurrency: 5
  }
);

Dadurch kann ein Worker mehrere Aufgaben parallel verarbeiten.

Konzeptionell gesehen:

Worker
 ├── Job 1
 ├── Job 2
 ├── Job 3
 ├── Job 4
 └── Job 5

Höhere Konkurrenz kann die Durchsatzrate steigern.

Aber erhöhen Sie die Konkurrenz nicht einfach auf 100, ohne es gründlich zu überdenken.

Falls jede Aufgabe auf Ihre Datenbank zugreift, kann eine hohe Konkurrenz diese leicht überlasten.

Die Einstellungen für die Konkurrenz sollten so angepasst werden, dass sie dem tatsächlichen Leistungsumfang Ihrer Arbeitslast entsprechen.

11. Rate Limiting

Mannchmal liegt das Engpassproblem überhaupt nicht in Ihrem eigenen System – sondern im Drittanbieterdienst, auf den Sie angewiesen sind.

Nehmen wir an, Ihr E-Mail-Anbieter begrenzt die Anzahl der Anfragen pro Sekunde auf einen festen Wert.

Falls Sie plötzlich:

10,000 jobs

nicht alle Anfragen auf einmal senden möchten.

Eine Warteschlange kann das Tempo steuern, mit dem Aufgaben verarbeitet werden.

Die resultierende Architektur sieht wie folgt aus:

10,000 Jobs
     ↓
Queue
     ↓
Rate Limit
     ↓
Worker
     ↓
External API

Das ist weitaus sicherer, als Tausende von gleichzeitigen Anfragen an einen Anbieter zu senden.

12. Die Idempotenz von Aufgaben ist wichtig

Dieses nächste Konzept gehört zu den wichtigsten Ideen bei der Verarbeitung von Hintergrundaufgaben.

Betrachten wir eine Zahlungsverarbeitungsaufgabe:

Process Payment

Der Worker führt sie aus.

Die Zahlung wird erfolgreich abgewickelt.

Aber kurz bevor der Worker sie als abgeschlossen markiert, stürzt der Prozess ab.

Die Warteschlange versucht, genau wie vorgesehen, die Aufgabe erneut auszuführen.

Ohne Schutzmaßnahmen könnte es dazu kommen, dass dem Kunden zweimal Gebühren in Rechnung gestellt werden.

Das ist ein echtes und kostspieliges Problem.

Um dies zu verhindern, sollten Aufgaben soweit wie möglich idempotent gestaltet werden.

In der Praxis bedeutet das, dass die Ausführung derselben Aufgabe zweimal keine unerwünschten doppelten Nebeneffekte verursachen sollte.

Ein gängiger Ansatz ist es, sich an einer eindeutigen Zahlungsreferenz zu orientieren:

payment:order_123

Dann sollte man vor der Ausführung jeglicher Arbeiten überprüfen:

Has this payment already been completed?
       ↓
     Yes → Don't charge again
       ↓
      No → Process payment

BullMQ selbst verfügt über keinen eingebauten Mechanismus dafür.

Es liegt an Ihrem Anwendungscode, die Idempotenz sicherzustellen.

13. Versagte Aufgaben benötigen eine Strategie

Nicht alle Fehler sind gleich, und nicht jeder von ihnen lohnt es, ihn erneut zu versuchen.

Betrachten Sie einige Beispiele:

Invalid email
Invalid user ID
Missing database record
Invalid payment information

Das Erneute Ausführen dieser Aufgaben fünfmal wird nichts lösen.

Es hilft, Fehler in zwei Kategorien einzuteilen:

Vorübergehende Fehler

Dazu gehören beispielsweise:

• Ein Netzwerkzeitüberschreiten
• Eine Abhängigkeit, die vorübergehend nicht verfügbar ist
• Eine unterbrochene Datenbankverbindung

Das sind die Arten von Problemen, bei denen es tatsächlich sinnvoll ist, später erneut zu versuchen.

Dauerhafte Fehler

Dazu gehören beispielsweise:

• Falsche Eingabedaten
• Eine referenzierte Ressource, die nicht mehr existiert

Verstoß gegen eine Geschäftsregel

Für solche Fälle ist ein erneuter Versuch sinnlos – die Aufgabe muss stattdessen direkt in einen Fehlerbehandlungsprozess geleitet werden.

Eine gut konzipierte Warteschlangenstruktur folgt nicht einfach nur einer pauschalen Regel:

Retry everything

Sondern einem überlegteren Ablauf:

Understand why it failed
       ↓
Temporary?
   /       \
 YES        NO
 ↓           ↓
Retry       Handle failure

14. Behandlung von fehlgeschlagenen Aufgaben

Egal wie vorsichtig man ist, einige Aufgaben werden auf eine Weise fehlschlagen, die durch erneute Versuche nicht behoben werden kann. Man benötigt Einblicke in diese Aufgaben, damit sie nicht einfach verschwinden.

Zum Beispiel kann es vorkommen, dass Folgendes entsteht:

Failed Jobs
──────────────
Job 101 → Email invalid
Job 102 → Payment failed
Job 103 → API timeout

Sobald man diese Fehler erkennen kann, hat man verschiedene Möglichkeiten:

• Den Fehler zur späteren Überprüfung aufzeichnen
• Das Team informieren
• Jemandem die Möglichkeit geben, manuell erneut zu versuchen
• Die fehlerhaften Daten korrigieren, die den Fehler verursacht haben
• Leiten Sie die Aufgabe in einen speziellen Workflow für das Umgang mit Fehlern um.

Die genaue Umsetzung hängt von den Anforderungen Ihres Systems ab. Am wichtigsten ist ein einziger Grundsatz:

Fehlerhafte Aufgaben sollten niemals spurlos verschwinden.

15. Warteschlange versus Cron-Aufgabe

Es ist leicht, diese beiden Konzepte zu verwechseln, doch sie lösen unterschiedliche Probleme.

Zur Aufgabe einer Cron-Aufgabe gehört es, Folgendes anzugeben:

"Führe diese Aufgabe zu einer bestimmten Zeit aus."

Zur Aufgabe einer Warteschlange gehört es, Folgendes anzugeben:

"Verarbeite diese Aufgabeneinheit."

In der Praxis arbeiten diese beiden Werkzeuge oft gut zusammen. Zum Beispiel:

Cron
 ↓
Find users whose trial expires today
 ↓
Create jobs
 ↓
Queue
 ↓
Workers
 ↓
Send emails

So bleibt die Scheduling-Logik getrennt von der Verarbeitungslogik. Das ist in der Regel ein saubereres Design als wenn ein einziger Cron-Prozess versucht, die gesamte Arbeit selbst zu erledigen.

16. Warteschlangenereignisse und Überwachung

Sobald Sie dies in der Produktion einsetzen, benötigen Sie Einblicke darüber, was tatsächlich innerhalb der Warteschlange vor sich geht.

Zu überwachende Metriken sind:

• Aufgaben, die abgeholt werden müssen
• Aufgaben, die derzeit verarbeitet werden
• Aufgaben, die erfolgreich abgeschlossen wurden
• Aufgaben, die fehlgeschlagen sind
• Die Dauer der Verarbeitung
• Anzahl der Wiederholungsversuche
• Gesamtkapazität der Warteschlange

Stellen Sie sich ein Dashboard vor, das plötzlich etwas wie Folgendes anzeigt:

Waiting Jobs

Normal: 50
Current: 25,000

Ein solcher Anstieg ist ein Warnsignal. Er kann bedeuten:

• Ihre Worker haben aufgehört zu laufen
• Eine externe API hat an Geschwindigkeit verloren
• Ihre Datenbank ist stark belastet
• Der Traffic ist stark angestiegen
• Eine kürzliche Bereitstellung hat einen Fehler mitgebracht

Falls Sie Ihre Warteschlange nicht überwachen, können sich diese Probleme unsichtbar anhäufen, bis die Benutzer bemerken, dass etwas nicht in Ordnung ist.

17. Legen Sie nicht alles in eine Warteschlange

Nur weil BullMQ verfügbar ist, bedeutet das noch nicht, dass jede einzelne Operation in einem Hintergrundjob ausgeführt werden muss.

Nehmen wir zum Beispiel Folgendes:

GET /profile

Hier wartet der Benutzer sofort auf seine Profildaten. Es macht keinen Sinn, dies in eine Hintergrundwarteschlange zu verschieben – das würde nur unnötige Verzögerungen verursachen.

Eine Warteschlange ist sinnvoll, wenn:

• die Aufgabe eine Weile dauert, um abgeschlossen zu werden
• die Aufgabe asynchron erledigt werden kann
• die Aufgabe möglicherweise wiederholt werden muss
• die Aufgabe viele Ressourcen verbraucht
• die Aufgabe von externen Diensten abhängt, die nicht zuverlässig sind
• das Ergebnis nicht Teil der unmittelbaren Antwort sein muss

Eine nützliche Frage ist:

Braucht der Benutzer dieses Ergebnis tatsächlich, bevor Sie die HTTP-Antwort zurücksenden?

Falls nicht, lohnt es sich, darüber nachzudenken, diese Aufgabe in einen Hintergrundprozess zu verlegen.

18. Eine Architektur im Produktionsstil

Wenn man all das zusammenfasst, sieht eine typische Konfiguration so aus:

Client
                       ↓
                  Node.js API
                       ↓
                ┌──────┴──────┐
                ↓             ↓
            PostgreSQL      Redis
                              ↓
                            Queue
                              ↓
                   ┌──────────┼──────────┐
                   ↓          ↓          ↓
                Worker 1   Worker 2   Worker 3
                   ↓          ↓          ↓
                Email      PDF       Notifications

Die API-Schicht kümmert sich um alles, was sofort erledigt werden muss. PostgreSQL (oder Ihre gewählte Datenbank) speichert die dauerhaften Geschäftsdaten. Redis unterstützt die Warteschlangeninfrastruktur sowie andere kurzlebige Arbeitslasten, bei denen es geeignet ist. Die Worker kümmern sich um alles, was asynchron ablaufen kann.

Durch diese Aufteilung der Verantwortlichkeiten lässt sich das gesamte System deutlich leichter skalieren.

19. Fehler, die man vermeiden sollte

Fehler 1: Alles innerhalb der HTTP-Anfrage erledigen

Dies führt zu APIs, die sowohl langsam als auch anfällig sind.

Fehler 2: Unbegrenztes Wiederholen

Manche Fehler werden sich einfach nicht von selbst lösen, egal wie oft man es versucht.

Fehler 3: Vernachlässigung der Idempotenz

Falls eine Aufgabe zweimal ausgeführt wird, können dadurch unerwünschte Doppelwirkungen entstehen.

Fehler 4: Zulassung unbegrenzter Parallelität

Ohne Grenzen besteht die Gefahr, dass die Systeme, von denen Ihre Aufgaben abhängen, überlastet werden.

Fehler 5: Vernachlässigung der Überwachung

Eine Warteschlange, die unkontrolliert wächst, stellt ein Betriebsproblem dar, das früher oder später auftauchen wird.

Fehler 6: Verwendung von Redis als Datenspeichersystem

Der Zustand der Warteschlange und die Kerngeschäftsdaten dienen unterschiedlichen Zwecken und sollten nicht miteinander verwechselt werden.

Fehler 7: Vollständige Asynchronisierung

Manche Operationen müssen tatsächlich abgeschlossen sein, bevor eine Antwort gesendet werden kann.

20. Ein besseres mentales Modell

Bevor man Schlangen versteht, ist der natürliche Impuls, sich die Abwicklung von Anfragen wie folgt vorzustellen:

Request
   ↓
Do everything
   ↓
Response

Ein nützlicheres Modell sieht hingegen so aus:

Request
   ↓
Do what must happen immediately
   ↓
Queue what can happen later
   ↓
Response

Danach folgt:

Queue
   ↓
Worker
   ↓
Process
   ↓
Retry if appropriate
   ↓
Complete / Fail

Diese Trennung – zwischen dem, was sofort erledigt werden muss, und dem, was später erledigt werden kann – ist die zentrale Idee hinter all dem.

Fazit

BullMQ ist nicht einfach deshalb nützlich, weil es eine weit verbreitete Node.js-Bibliothek ist. Es ist nützlich, weil die Verarbeitung von Hintergrundaufgaben einen echten architektonischen Bedarf adressiert.

Falls eine Aufgabe:

• langsam ist
• eine Aufgabe ist, die wiederholt werden kann
• eine Aufgabe ist, die die Antwort nicht blockieren muss
• von einem externen Service abhängt
• ressourcenintensiv ist

dann sollte sie vermutlich nicht im HTTP-Anfragenzyklus ausgeführt werden.

Eine Warteschlange sorgt dafür, dass die Aufgabe einen Platz zum Ausführen erhält. Redis stellt die zugrundeliegende Infrastruktur bereit. BullMQ kümmert sich um die Verwaltung der Aufgaben. Die Worker führen die eigentliche Verarbeitung durch. Wiederholungsversuche kümmern sich um vorübergehende Fehler. Einstellungen zur Parallelisierung halten die Durchsatzrate unter Kontrolle. Die Überwachung informiert Sie, wenn etwas nicht in Ordnung ist. Zudem sorgt ein durchdachtes Design auf Anwendungsseite dafür, dass Aufgaben bei Bedarf sicher mehrmals ausgeführt werden können.

Die wichtigste Lektion hier lautet:

Nicht alles muss innerhalb des Anfrage-Antwort-Zyklus gelöst werden.

Mannchmal ist die richtige Antwort einfach:

"Ich habe die Aufgabe angenommen. Wir kümmern uns um den Rest."

Verwandte Artikel

• Entwurf von Real-Time-Chat-Backends: Räume, Persistenz und Skalierung — Erfahren Sie, wie man ein Real-Time-Chat-Backend mithilfe von Socket.IO, PostgreSQL und Redis architektonisch gestaltet, wobei Themen wie Räume, die Reihenfolge der Nachrichtenpersistenz, Präsenz und Multi-Server-Skalierung behandelt werden.
• Grundlagen des Redis-Caching: Muster, Fallstricke und Fragen in Vorstellungsgesprächen — Lernen Sie, wie das Redis-Caching in Node.js-Anwendungen funktioniert, von Cache-Aside und TTL über Schutzmaßnahmen gegen Überlastung, Eviction-Politiken bis hin zu gängigen Fragen in Vorstellungsgesprächen.