Die Technik hinter Vowly Event: digitale Hochzeitseinladungen und Online-RSVP
Eine Hochzeitseinladung ist ein verteiltes System im festlichen Kleid: eine Nachricht, hunderte Empfänger und eine Gästeliste, die sich bis zur Hochzeitswoche ständig ändert.
Vowly Event tut etwas, das einfach klingt, bis man es baut: Es versendet digitale Hochzeitseinladungen und sammelt die Antworten online. Ein Paar, eine Gästeliste, hunderte Menschen, die jeweils etwas Persönliches erhalten und etwas zurücksenden müssen. Wir bauen und betreiben das Produkt — so denken wir über die Teile, die schwieriger sind, als sie aussehen.
Die Gästeliste ist das Produkt
Die meisten halten die Einladung für das Produkt. Sie ist es nicht. Die Einladung ist die sichtbare Oberfläche; die Gästeliste trägt das gesamte Gewicht. Sie wird permanent bearbeitet, bis in die Woche der Hochzeit hinein. Namen werden korrigiert, Begleitungen kommen dazu, nach einem Telefonat mit den Eltern wird eine ganze Familie ergänzt, und einige wenige werden still gestrichen.
Das heißt, das Datenmodell darf einen Gast nicht als einmalig geschriebene Zeile behandeln. Ein Gast ist eine kleine Historie: eingeladen, geöffnet, geantwortet, umentschieden, zurückgewechselt. Wer nur den aktuellen Zustand modelliert, kann die Frage nicht beantworten, die Paare tatsächlich stellen — nicht „wie viele kommen“, sondern „wer hat noch nicht geantwortet, und hat die Person die Einladung überhaupt geöffnet“.
Haushalte statt Einzelpersonen
Die zweite Modellierungsentscheidung, die sich auszahlt, ist die Gruppierung. Einladungen gehen an Haushalte, nicht an Personen. Eine vierköpfige Familie erhält eine Einladung und antwortet einmal — aber Sitzplan, Cateringzahl und Ernährungshinweise brauchen Einzelpersonen. Wer das früh falsch macht, zwingt jedes spätere Feature zu Umwegen. Gast-Entität und Einladungs-Entität sollten ab dem ersten Commit getrennt sein.
Traffic, der in Wellen kommt
Hochzeits-Traffic ist keine gleichmäßige Kurve. Ein Paar verschickt die Einladungen am Sonntagabend, und ein großer Teil der Liste öffnet den Link in den folgenden zwei Stunden. Dann passiert eine Woche lang fast nichts. Dann kommt eine zweite Spitze, wenn die Erinnerung rausgeht.
Diese Form belohnt bestimmte Entscheidungen. Die Einladungsseite selbst sollte statisch oder nahezu statisch sein und aus einem Edge-Cache ausgeliefert werden, denn sie ist für jeden Gast eines Haushalts identisch und fängt die Welle ab. Der Schreibpfad — die RSVP-Übermittlung — ist der einzige Teil, der wirklich eine Datenbank braucht, und macht einen Bruchteil der Requests aus. Diese Trennung bedeutet, dass die teure Infrastruktur nur für die Antworten dimensioniert werden muss, nicht für die Aufrufe.
Zustellung ist der unglamouröse schwere Teil
Ein paar hundert Nachrichten zu versenden ist einfach. Dafür zu sorgen, dass sie alle ankommen, nicht. Einladungen laufen über Kanäle, die der Absender nicht kontrolliert, und eine Nachricht im Spam-Ordner ist aus Sicht des Paares nicht von einem Gast zu unterscheiden, der sie ignoriert.
- Die Absenderdomain sauber authentifizieren — SPF, DKIM und DMARC sind nicht optional, wenn das gesamte Produkt von Zustellung abhängt.
- Öffnungen und Klicks pro Gast erfassen, damit das Paar sieht, wer die Einladung wirklich nicht gesehen hat, statt zu raten.
- Jeder Einladungslink muss ohne Konto funktionieren. Eine Login-Hürde zwischen Gast und RSVP-Formular kostet Antworten.
- Damit rechnen, dass manche Gäste stattdessen beim Paar anrufen. Manuelle Erfassung muss ein vollwertiger Weg sein, kein Admin-Behelf.
Wo die App hineinpasst
Vowly Event gibt es auch als App im App Store und bei Google Play. Die sinnvolle Aufteilung: Die Web-Oberfläche gehört dem Gast, die App dem Paar. Gäste sollten nie etwas installieren müssen; sie bekommen einen Link und ein Formular. Das Paar, das über Monate dutzende Male hineinschaut, bekommt die reichere Oberfläche, in der die Gästeliste lebt.
Was wir einem anderen Team raten würden
Bauen Sie zuerst die Gästeliste, danach die Einladungsdesigns. Behandeln Sie Zustellbarkeit als technisches Problem mit Messwerten, nicht als Einstellung, die man einmal vornimmt. Und dimensionieren Sie für die Lese-Welle, nicht für den Durchschnitt — der Durchschnitt ist bedeutungslos, wenn der Traffic in Zwei-Stunden-Wellen ankommt.
Weiterlesen
Arbeiten Sie an etwas Ähnlichem?
Wir bauen und betreiben die hier beschriebenen Systeme. Schildern Sie uns Ihr Vorhaben und Sie erhalten eine ehrliche technische Einschätzung.