Seit einiger Zeit arbeite ich jetzt als Java Developer bei der trivago GmbH. Zum ersten Mal durfte ich nun auch an den trivago Developer Days teilnehmen, welche vom Konzept her etwas an die Google’sche 20% Regelung erinnern. Wir Developer bekommen in regelmäßigen Abständen 3-4 Tage Zeit, sich ein Projekt auszuwählen (aus dem internen Ideenportal oder aus eigener Motivation) und dieses Umzusetzen. Für mein erstes DevDays Projekt habe ich mich, zusammen mit Christian Krause (@redbrick) an ein Mail Delivery System gesetzt. Drei Tage (plus ein Halber für das Vorbereiten der Präsentation und ein weiterer Halber für das Setup) sind nun nicht viel, auch wenn man die Definition von „Tag“ irgendwo zwischen acht und 14 Stunden ansiedeln kann. Wir haben uns also auf die Kern-Features beschränkt, die wir selbst von einem solchen System erwarten würden. Klar war, dass Mail-Delivery die Kernkompetenz sein sollte. Wir wollten jedoch, auf der Delivery Schicht basierend, auch eine Applikation erstellen, damit der Nicht-Tekkie auch etwas davon hat. So ist die Idee des Newsletter Systems entstanden, welchem wir den Arbeitstitel Mail-Pigeon verpasst haben. Die Wunsch-Features im Überblick: Mail-Delivery:
- Versand über mehrere Clients (horiz. Skalierbarkeit)
- Kein Datenverlust beim Absturz einer oder aller Sending-Daemons
- Bounce Handling (zumindest erst mal rudimentär)
- Ein Datenformat, dass sowohl von PHP und JavaScript, als auch von Java beherrscht wird. Bleibt nicht viel: XML und JSON. Und XML war es nicht 😉
Newsletter System:
- Absender Management (Durch die vielen Nationen und Sprachen bei trivago haben wir sehr verschiedene Absender)
- Empfänger und Empfängergruppen
- Newsletter und Vorlagen für neue Newsletter sowie Personalisierungsmöglichkeiten
- Wirkungsgradbestimmung durch Trackingpixel und Kampangen
- Live Versandstatus und Fortschritt
- Tagging für einen Versand
Als Technologien kamen Neo4J, eine GraphDB, RabbitMQ, eine MessageQueue und Vaadin, ein auf GWT basierendes UI Framework zum Einsatz. Ich werde alle Technologien, deren Verwendung und eine kurze Begründung zur Wahl im Folgenden anreißen.
RabbitMQ ist ein MessageQueue Server, der von VMWare’s SpringSource Devision in Erlang entwickelt wird. Die Wahl fiel auf RabbitMQ, weil er sowohl AMQP und JSONRPC over AMQP, als auch STOMP unterstütz und damit für alle bei trivago eingesetzten Sprachen erreichbar ist. RabbitMQ ist zudem hochperformant und kommt unserem Vorhaben, Tonnen von Mail zu versenden, zu Gute.
Neo4J ist eine
Graphdatenbank, geschrieben in Java. Neo4J unterstützt sowohl gerichtete, als auch gewichtete Kanten, ebenso wie Eigenschaften an Knoten. Das Konstrukt wird ergänzt durch einen Lucene Index für Knoten, über den man recht schnelle Key-basierte Lookups durchführen kann. Die Wahl fiel deswegen auf eine GraphDB, weil sie am sinnvollsten unsere Daten abbildet. Es entstehen sehr viele Beziehungen zwischen den Entitäten unserer Applikation, die durch RDBMS – JOIN – Konstrukte sicherlich nur unter hohem Rechenaufwand abbildbar wären.Ein Beispiel ist die Relationsmenge zwischen Empfänger (E), Empfängergruppe (G) und versendetem Newsletter (N). Hier gibt es folgende Relationen abzubilden:
-
-
-
-
G -> enthält Empfänger -> E
Nehmen wir noch einen weiteren Knotentype „Bounce“ (B) hinzu, wird das Konstrukt noch etwas interessanter:
-
N <- ist hard-bounced <- B -> ist hard-bounced -> E
-
N <- ist soft-bounced <- B -> ist soft-bounced -> E
Damit lässt sich also recht schnell darstellen, welcher Bounce-Typ bei welchem Newsletter oder Empfänger vorkam. Kanten lassen sich übrigen mit linearem Aufwand zählen, wenn man den Knoten kennt!
Vaadin ist ein auf dem Google Web Toolkit basierendes UI Framework. Ich bin kein großer HTML/CSS Künstler, also musste etwas anderes her, was erwachsen und optisch ansprechend war. Mit Vaadin konnte ich im Liferay – Bereich schon mal Erfahrungen sammeln und fand es schon damals sehr ansprechend. Wer mal Swing oder AWT benutzt hat, der wird sich bei Vaadin recht schnell heimisch fühlen. Jedenfalls bekommt man bei Vaadin jede Menge „geschenkt“, was Optik, Kompatibilität und Technologie angeht. Ich kann euch nur den
Sampler ans Herz legen, dann versteht ihr was ich meine 😉
Personalisierung haben wir durch das Einbetten von
Apache’s Velocity erreicht. Die Mail Templates, aus denen man neue Newsletter erstellen kann, können in Velocity geschrieben werden. Beim Versand wird der Template-Context mit den Daten des Empfängers, der Gruppe, der Kampange und Metadaten befüllt und für jeden Empfänger evaluiert. So wird eine komplette Personalisierung ermöglicht.
Tracking wird durch das automatische Einfügen eines
![]()
Tags in die HTML Version der Mail erledigt. Das Image ruft ein separates Servlet auf, welches den Newsletter und die Empfänger ID benötigt. In der Folge kann dann die gerichtete Kante E -> hat geöffnet -> N erstellt werden.
Tagging erscheint vielleicht auf den ersten Blick für einen Newsletter ein wenig sinnfrei. Wenn man jedoch die GraphDB in die Rechnung mit einbezieht und das Tracking hinzu nimmt, dann entsteht die Möglichkeit „User-Interest-Tracking“. Die Kobination Tag (T) sieht dann z. B. folgendermaßen aus (Die Pipe soll zwei Kanten darstellen):
T <- hat Tag <- N <- hat empfangen | hat geöffnet <- E.
Aus diesen Relationen können wir also, bei entsprechender Skalierung, ablesen, für welche Tags sich ein Empfänger interessiert.
Kategorien
