Zurück zum Blog
Webhook vs. Polling: Warum JunkMail Echtzeit gewählt hat (und warum Sie das auch sollten)

Webhook vs. Polling: Warum JunkMail Echtzeit gewählt hat (und warum Sie das auch sollten)

Entdecken Sie die technische Architektur hinter JunkMail. Wie wir Tausende von E-Mails pro Sekunde verwalten, ohne Ihre Testskripte jemals warten zu lassen.

Von Engineering Team7.1.2026

In der Welt der Entwicklung gibt es ein Versprechen, das oft gebrochen wird: "Echtzeit".

Wie oft haben Sie ein Skript programmiert, das auf ein externes Ereignis warten muss (wie den Eingang einer E-Mail), nur um am Ende eine while(true)-Schleife zu schreiben, die eine API alle zwei Sekunden bombardiert? Das nennt man Polling. Und im Jahr 2026 ist das ein bisschen so, als würden Sie alle 5 Minuten Ihren physischen Briefkasten überprüfen, um zu sehen, ob der Postbote da war.

Bei JunkMail haben wir unsere Infrastruktur auf dem gegenteiligen Prinzip aufgebaut: dem Webhook.

Tauchen wir unter die Haube, um zu verstehen, warum diese Wahl alles für Ihre Tests und Ihre Anwendungen ändert.

Polling: Der stille Ressourcenfresser

Polling ist die "Holzhammer"-Methode. Ihre Anwendung fragt JunkMail: "Habe ich Post? Nein. Und jetzt? Nein. Und jetzt? Immer noch nicht."

Warum es eine schlechte Idee ist:

  1. Ressourcenverschwendung: Jede Anfrage verbraucht Bandbreite und CPU sowohl auf Ihrem Server als auch auf unserem.
  2. Künstliche Latenz: Wenn Sie alle 10 Sekunden abfragen, könnten Sie die E-Mail mit 9,9 Sekunden Verzögerung erhalten. In einer CI/CD-Pipeline von 500 Tests wird diese Verzögerung inakzeptabel.
  3. Kosten: APIs begrenzen oft die Anzahl der Anfragen pro Minute (Rate Limiting). Polling lässt Sie diese Grenzen sehr (zu) schnell erreichen.

Webhook: "Rufen Sie uns nicht an, wir rufen Sie an"

Der Webhook ist der elegante Ansatz. Sie geben JunkMail eine URL (Ihren Endpunkt), und wir bleiben still. Sobald eine E-Mail ankommt und unsere Filter passiert, "pushen" wir die Daten sofort zu Ihnen.

Die Vorteile sind massiv:

  • Sofortige Reaktionsfähigkeit: Sobald der Haraka-SMTP-Server den Empfang der Mail beendet hat, ist sie in Millisekunden vor Ihrer Haustür.
  • Effizienz: Eine einzige HTTP-Anfrage nur dann, wenn es notwendig ist.
  • Skalierbarkeit: Ihr Server kann Tausende von eingehenden E-Mails verwalten, ohne komplexe Warteschleifen aufrechterhalten zu müssen.

Die JunkMail-Architektur: Eine Symphonie in vier Sätzen

Um diese Echtzeit möglich zu machen, verwendet JunkMail einen Tech-Stack, der auf reine Leistung optimiert ist.

1. Der Empfang (Haraka SMTP)

Wir verwenden Haraka, einen ultraschnellen SMTP-Server, geschrieben in Node.js. Im Gegensatz zu traditionellen Servern (Postfix, Exim) ist Haraka ereignisgesteuert. Es erlaubt uns, die E-Mail abzufangen, während sie ankommt, und unsere Skripte sofort auszulösen.

2. Das Gehirn (NestJS & Redis)

Sobald die Mail empfangen wurde, wird sie an unsere NestJS-API gesendet. Der Inhalt wird ephemer in Redis, einer In-Memory-Datenbank, gespeichert. Warum Redis? Weil das Schreiben auf eine Festplatte für unsere Standards zu langsam ist.

3. Die Benachrichtigung (Webhooks & WebSockets)

Hier geschieht die Magie.

  • Für Ihre Tests: Wenn Sie einen Webhook konfiguriert haben, sendet unser System eine POST-Anfrage an Ihre URL mit dem JSON-Inhalt der Mail.
  • Für Ihr Dashboard: Wir verwenden WebSockets (Socket.io). Das ist der Grund, warum Ihre JunkMail-Oberfläche blinkt und die E-Mail anzeigt, ohne dass Sie die Seite aktualisieren müssen.

4. Die Reinigung (Cron & TTL)

Daten leben, aber sie müssen sterben. Wir verwenden die TTL (Time To Live)-Mechanismen von Redis und geplante Aufgaben (Cron), um sicherzustellen, dass Ihre E-Mails nach 24h oder 30 Tagen, je nach Ihrem Plan, wirklich verschwinden.


Anwendungsfall: Warum Entwickler unsere Webhooks lieben

Stellen Sie sich vor, Sie testen einen Zahlungsfluss, der eine Rechnung sendet.

Ohne Webhook: Ihr Playwright-Test muss Schleifen drehen, Timeouts behandeln und verpasst möglicherweise die E-Mail, wenn das Netzwerk zuckt. Ihr Code ist übersät mit sleep(5000).

Mit JunkMail Webhook: Ihr Test startet einen winzigen temporären HTTP-Server (über eine Bibliothek wie express oder msw). Er konfiguriert die Webhook-URL auf JunkMail. Er wartet einfach auf die POST-Anfrage. Sobald sie ankommt, fährt der Test fort. Ergebnis: Ihre Tests sind 5x schneller und 100% stabil.

Fazit

JunkMails Architektur wurde nicht entworfen, um einfach nur "Post zu speichern". Sie wurde als Echtzeit-Dateninfrastruktur konzipiert.

Indem wir Webhooks statt Polling wählen, bieten wir Ihnen das präziseste Werkzeug auf dem Markt für Ihre Automatisierungen. Denn wir wissen, dass Ihre Zeit die wertvollste Ressource in Ihrem Stack ist.

Bereit, einen Gang hochzuschalten? Richten Sie Ihren ersten Webhook auf JunkMail Business ein.