Why does the check-in scanner have no offline mode?

Because an offline mode could not do the one thing that matters. The server is the only place that knows whether a guest's admission allowance is already spent, so a device that cannot reach it cannot verify anything. An offline queue would therefore record unverified admissions and surface the problem only after the guest was inside. Instead the scanner reports the lost connection, records nothing, and hands the decision to a staff member. For a sensitive guest list, refusing to fake a verification is the security feature rather than a limitation.

What happens if a guest forwards their invitation to someone else?

It cannot add anyone to the room. Every guest's code is unique to them and carries an admission allowance, and the server refuses the code once that allowance is spent. The allowance matters because real guest lists include companions, so someone invited with a partner legitimately opens the door twice. What cannot happen is an admission nobody granted. Those limits are enforced atomically, so two doors scanning the same guest at the same instant cannot both admit.

How do multiple check-in stations stay in sync?

They do not need to, because they hold no guest list and no admission state of their own. Every station asks the same server in real time, so there is no merge step and no window in which two doors believe different things about the same guest. Admission limits are enforced atomically on the server, which means two entrances scanning the same person simultaneously cannot both admit. The design removes the class of synchronization bug rather than managing it.

Event Invitation System for High-Trust Guest Lists

The Event Invitation System Behind a Diplomatic Guest List

The German Embassy in Manila runs its receptions on an event invitation system Pegotec built and operates. Formal events put a particular demand on software. The guest list is confidential, the invitation has to arrive, and the door has to move quickly without admitting anyone who should not be there. Here is what the system actually gives an organizer.

Invitations that land in the inbox

An invitation that reaches a junk folder has failed, however elegant the rest of the system is. So invitations go out in capped batches rather than one burst, which works out at roughly four to five seconds each.

A thousand invitations therefore take an hour and a half to two hours. Corporate mail systems treat a sudden flood as bulk, and batching avoids that judgment entirely.

The result on this year’s send, across a four-figure list: zero send failures and a 2.7% bounce rate. Last year’s campaign was roughly the same size.

Nobody gets invited twice

At this level of event a duplicate invitation is the embarrassing failure, so the system refuses one at three separate layers.

A database constraint makes an identical second send impossible outright. Credit accounting then reserves before sending and refunds on failure, so a crash mid-run cannot silently double-charge or double-deliver. Finally, when the mail provider times out, the system searches the provider for the message it may already have accepted and adopts that one rather than sending again.

That third layer matters most. A timeout is not a failure — it is an unknown, and treating unknowns as failures is exactly how guests receive two invitations.

Delivery status does not depend on one channel

Most systems trust their email provider’s callbacks. This one does not.

When provider notifications stop arriving, a reconciler keeps polling for deliveries, opens and bounces independently. Consequently the organizer’s view of who received what never rests on a single channel staying healthy. We exercised that path for real this month.

Suppression is deliberately narrow too. A permanent delivery failure blocks future mail only when it occurred on the guest’s own address — not when a colleague copied on the invitation has a dead mailbox. That distinction costs real engineering effort, and it stops somebody else’s bounce from silencing a working mailbox.

A guest list that stays the guest list

Every guest’s code is unique to them. The server refuses it once that guest’s allotted admissions are used up.

The allowance matters, because real guest lists include companions. Someone invited with a partner legitimately opens the door twice. What cannot happen is an admission nobody granted, so a forwarded invitation never adds a guest to the room.

The server enforces those limits atomically. Two doors scanning the same guest at the same instant therefore cannot both admit.

An event invitation system where every door tells the same truth

Multi-door events usually raise a synchronization question. This one does not, because the stations hold no guest list and no admission state of their own.

Each station asks the same server in real time. There is consequently no merge step and no window in which two entrances believe different things about the same guest. Open a second door ten minutes before the rush and it is simply correct from the first scan.

The system never guesses

One design decision underpins the rest. The server is the only place that knows whether a guest’s allowance is already spent, so a scanner that cannot reach it cannot verify anything.

Rather than quietly queueing admissions and reconciling later, the scanner reports the lost connection plainly and hands the decision to your staff. It records nothing. An offline queue would log unverified entries and surface the problem only after the guest walked in.

Consequently, a confirmed check-in on this system always means the same thing. That is what makes the rest of the guarantees on this page worth anything.

Deployments that prove themselves

One lesson came from an incident rather than a design session. Deployments were reporting success while shipping nothing.

Now the deploy refuses to run against an environment that does not match its intended target, and afterwards it verifies that the code actually running is the code that was built. For a system that only matters on a handful of evenings a year, “we deployed the fix” needs to be a fact rather than an assumption.

Scoping and retention

The system scopes access per client and enforces it on every query, so one organizer cannot reach another’s data.

It also deletes generated invitation documents automatically after thirty days. Those PDFs carry names and codes, and they exist only to reach a guest, so they should not accumulate.

Sizing the door

The useful planning rule is to size entrances by arrival pattern rather than by headcount. Guests do not arrive evenly, so the busiest half hour decides your staffing, not the total on the list.

A scan is a handful of indexed queries inside one transaction, so the server is rarely the constraint. The queue forms at the human step instead — finding the code, greeting the guest, handling the person who forgot theirs.

Discretion is part of the specification

We name clients, or we publish the operational detail of their events. We do not do both.

Guest counts, door staffing and throughput at a named embassy’s reception would together describe that event to anyone who wanted to know. Furthermore, the mechanisms protecting device access stay unpublished for the same reason.

A vendor willing to publish those details about one client will publish them about the next one. Treat that restraint as a feature you are buying.

How Pegotec helps

We build and operate the Event Invitation Management System for formal and private events, and we run it as a service rather than handing over software and walking away. Embassies, chambers, foundations and corporate hosts use it for events where the guest list itself is sensitive.

If you are planning an event of that kind, talk to us.

FAQ

Let's Talk About Your Project

Enjoyed reading about The Event Invitation System Behind a Diplomatic Guest List? Book a free 30-minute call with our consultants to discuss your project. No obligation.

Book a Free Call