Engineering Vowly Event: digital wedding invitations and online RSVP

Vowly Event does something that sounds simple until you build it: it sends digital wedding invitations and collects the replies online. One couple, one guest list, hundreds of people who each need to receive something personal and send something back. We build and maintain it, and this is how we think about the parts that are harder than they look.

The guest list is the product

Most people think the invitation is the product. It is not. The invitation is the visible surface; the guest list is the thing that carries all the weight. It is edited constantly, right up to the week of the wedding. Names get corrected, plus-ones appear, whole families are added after a phone call with a parent, and a handful of people are quietly removed.

That means the data model cannot treat a guest as a row that is written once. A guest is a small history: invited, viewed, replied, changed their mind, changed it back. If you model only the current state you lose the ability to answer the question couples actually ask, which is not "how many are coming" but "who has not replied yet, and did they even open it".

Households, not individuals

The second modelling decision that pays for itself is grouping. Invitations go to households, not to people. A family of four gets one invitation and replies once, but the seating chart, the catering count and the dietary notes all need individuals. Getting this wrong early means every downstream feature has to work around it, so the guest entity and the invitation entity should be separate from the first commit.

Traffic that arrives in bursts

Wedding traffic is not a smooth curve. A couple sends invitations on a Sunday evening and a large share of the guest list opens the link within the next two hours. Then almost nothing happens for a week. Then there is a second spike when the reminder goes out.

This shape rewards a specific set of choices. The invitation page itself should be static or near-static and served from an edge cache, because it is the same for every guest in a household and it is what receives the burst. The write path — the RSVP submission — is the only part that genuinely needs to hit a database, and it is a tiny fraction of the requests. Separating the two means the expensive infrastructure only has to be sized for the replies, not for the views.

Delivery is the unglamorous hard part

Sending a few hundred messages is easy. Sending them so that they all arrive is not. Invitations go out over channels the sender does not control, and a message that lands in a spam folder is indistinguishable, from the couple's point of view, from a guest who is ignoring them.

• Authenticate the sending domain properly — SPF, DKIM and DMARC are not optional when the entire product depends on delivery.
• Track opens and clicks per guest so the couple can see who has genuinely not seen the invitation, rather than guessing.
• Make every invitation link work without an account. A login wall between a guest and an RSVP form costs replies.
• Assume some guests will reply by phone to the couple instead. Manual entry has to be a first-class path, not an admin hack.

Where the app fits

Vowly Event also ships as a mobile app on the App Store and Google Play. The useful division is that the web surface belongs to the guest and the app belongs to the couple. Guests should never be asked to install anything; they get a link and a form. The couple, who will open the product dozens of times over months, get the richer surface where the guest list lives.

What we would tell another team

Build the guest list first and the invitation designs second. Treat delivery as an engineering problem with metrics attached, not as a feature you configure once. And size your infrastructure for the read burst, not the average — the average is meaningless when your traffic arrives in two-hour waves.