Registration load rehearsal: how to test check-in

A practical plan for accepting registration under load: peak scenarios, safe data, failover, PASS/FAIL criteria and the contractor's report.

What must a load rehearsal prove?

A registration load rehearsal must show that the entire guest journey works under real traffic: the record is found, the QR code is scanned, the status changes once, the badge is printed, and the result is visible at neighbouring workstations. Here check-in means finding the record and recording the guest's arrival. A successful response from a single form or a beep from the scanner does not yet prove that the whole process is ready.

At Aventura, we first define the scope of the test. The guest presents an invitation or asks for their record to be found. The system checks the status, records the arrival and sends the data to print.

The operator receives a clear confirmation. The dependency map also includes external services.

The overall registration journey is described in detail in the article on event participant registration. Here the task is narrower: to test this journey under load and get a pass or fail decision based on pre-recorded criteria.

The scanner may beep after successfully decoding the barcode. This confirms that the device has read the symbol, but not that a new status has been recorded in the central system. Therefore, the observer checks the operator's screen, the guest card, the printout and the final export, not just the scanner's response.

Peak traffic in the client's terms

We define the peak through the guest arrival scenario, not through a round number of virtual users. The client describes arrival windows, the share of the main group, multiple entrances, manual cases and simultaneous operations. The technical team calculates how many operations start each minute and how long each stage takes.

For conference organisation, it is useful to compile the transport schedule, the start of the plenary session, access to the breakout rooms and the rules for distributing materials. A bus or the end of a general block creates a step in demand. Guests continue to arrive even when previous operations have already slowed down.

The minimum model contains:

• the number of expected guests by time window;
• the share of QR, manual search and guests without pre-registration;
• the number of entrances, desks, scanners and printers;
• the share of repeat scans and reprints;
• late changes of status or category;
• dependencies on the network, email, SMS and external databases.

Such a profile allows technical load to be compared with the visible queue. The server may respond quickly, yet the workstation still serves the guest slowly because of search, printing or an unclear error. Therefore, the system operation and the full cycle at the desk are measured separately.

Which operations should be included in the scenario?

The scenario should replicate the business operations the team performs at the entrance, including exceptions. Testing a single registration page gives a false sense of readiness. The main flow is run together with manual search, a repeat QR, late registration and printing, so you can see contention for shared resources and how complex cases affect the queue.

We build the journey like this:

1. The guest presents a QR code or gives their details for a search.
2. The operator finds the one correct record.
3. The system checks the current status and access rights.
4. Check-in changes the status exactly once.
5. The printer issues a badge with the current category.
6. The neighbouring desk sees the change without manually refreshing the data.
7. The final export contains a single confirmed check-in.

The scenario also includes a typo, a namesake, a case with no QR code, an already used code, late registration and a request for a duplicate badge. A detailed set of media can be checked against the article on secure QR codes at events, without turning the load run into a separate QR security audit.

A late change must also go through the entire loop. A record is created or changed after the control export, then search, rights, printing and propagation of the new status are checked. The companion piece on late registrations helps prepare such a scenario without repeating the entire project calendar.

Registration is built into event production as a whole. If you need the overall framework of the venue, contractors and entrance team, take a look at business event organisation: we agree roles, control points and fallback solutions in advance.

We also publish practical breakdowns of venue preparation and team work in the Aventura Telegram channel.

Three test run modes

Our acceptance protocol uses three modes: a quick check of the basic chain, the expected working flow, and a sharp spike. They answer different questions. One smooth ramp-up can hide a scenario error, while a maximum-capacity search does not confirm that the agreed peak meets business criteria.

The k6 documentation has separate modes for a baseline check, normal load, overload, a sharp spike and finding the system limit. The client does not have to understand how the tool is configured, but does need to understand the purpose of the run.

One mode shows the reaction to a sudden influx, another searches for the limit. A working run confirms a specific event scenario.

Before a large rehearsal, the team does a baseline run of each path. It catches incorrect test records, missing permissions and integration errors. After that, the load is increased according to the agreed profile, not according to a technical specialist's improvisation.

How to prepare safe test data

For a rehearsal, it is best to use synthetic profiles that replicate the structure of the guest database without real contact details. The set includes various roles and categories. Individual records mimic similar surnames, late changes and exceptions. Before launch, the team agrees on access rights and the deletion deadline, and moves external mailings to a safe test environment.

The principles of Article 5 of Federal Law No. 152-FZ require a specific processing purpose, data that matches that purpose, and no redundancy. For a load test, this is a practical argument against copying the production database "for realism" if the same scenario can be reproduced with fictitious records.

The set is prepared step by step:

1. Identify the fields and statuses that are actually involved in check-in.
2. Create synthetic records of the required categories and distribution.
3. Separately flag records for QR re-use, late changes and reprinting.
4. Restrict operator and observer access to test roles.
5. Block the sending of emails and messages to real recipients.
6. Set a deletion deadline for records, logs and exports after acceptance.

Legal requirements for forms and consents must be verified separately. There is a dedicated material on the registration form under 152-FZ. In the load rehearsal, we test an already approved data schema. The composition of test records, access rights, logging and retention periods are agreed with the data protection officer or a lawyer.

PASS/FAIL criteria before launch

PASS/FAIL means "passed / not passed" against a criterion recorded in advance. Write down the acceptance criteria before the test and tie them to the promised guest journey. There is no universal standard for latency or number of operations. The project team sets the acceptable throughput, errors, service time and stop rules, then compares the actual result against them without adjusting the thresholds after the fact.

k6 threshold conditions automatically mark whether the criterion for a metric has passed. Specific values from the documentation cannot be carried over into the project as a benchmark. They are defined by the system owner, the client and the operations team, taking into account the acceptable queue and the promised service.

A special criterion concerns the load generator. If the planned operations were not started, the report describes a lower throughput than stated. The dropped_iterations metric helps separate degradation of the system under test from a lack of resources or incorrect configuration of the generator itself.

What to break during a rehearsal?

During a rehearsal, we take turns disabling or slowing down individual dependencies within an agreed window: network, printer, external service, or a single workstation. The team checks detection speed, message clarity, and transition to backup. Each failure is triggered according to a scenario with the right to stop immediately and a pre-assigned run leader.

A useful set of failures:

• slow or temporarily unavailable network;
• failure of a single scanner or printer;
• lost response after a check-in that was actually completed;
• HTTP "Too Many Requests" response indicating a pause before retry;
• unavailable external database or printing service;
• operator re-clicking due to unclear status;
• dependency recovery after manual marks.

Immediate automatic retries can create a new wave of requests: an already overloaded service receives even more calls and takes longer to recover. If the operation changes the guest's status, a blind retry can create a duplicate. The system must distinguish between a safe retry, waiting, and manual verification of the result.

The network part is best coordinated with the venue's infrastructure owner. The article about guest Wi-Fi at a conference explains why service registration cannot be evaluated with a single common speed test together with guest traffic.

Desks, QR codes, and feedback

The lab test is supplemented by an on-site run at real desks, devices, and media. The team checks phone screens with different brightness, paper codes, glare, re-presentation, and noise. The operator must see an unambiguous outcome of the operation that does not depend solely on sound or color in the interface.

GS1 links the readability of a two-dimensional code to the clear space around the symbol, contrast, a flat grid, and the absence of graphical noise. Therefore, the run includes the sizes, materials, and display methods that guests will encounter. A perfect test image on a monitor does not replace a real medium.

In our scenario, we check six distinguishable states: "code read", "verification in progress", "entry confirmed", "already marked", "record not found", and "no connection". The W3C guidance on status messages requires that a state change can be determined programmatically without forcing focus. For a desk, this is also a matter of staff training speed.

The physical layout of entrances, queues, and equipment placement must be considered when choosing a venue. The system may pass a server test but lose throughput due to a narrow lobby, a shared line for multiple categories, or a printer that operators reach through the guest flow.

How do you test the backup and recovery?

A backup is only considered working after an actual switchover, continued check-in and reconciliation back. If a local or offline mode is claimed, the team disconnects the primary dependency, accumulates transactions, restores the connection and checks for conflicts. If there is no offline mode, they rehearse the manual process and a single switchover command for all desks.

The recovery scenario runs as follows:

1. The drill lead announces the failure of the selected dependency.
2. The team records the detection time and the visible symptom.
3. The senior registration officer issues one agreed switchover command.
4. Operators continue check-in along the backup route.
5. The observer records manual and local marks.
6. The primary service is restored in the agreed order.
7. Data is reconciled, conflicts are resolved, and the final version is confirmed.

A detailed diagram of the connection and work with local lists is in the article about an event without mobile internet. In the current rehearsal, the transition points and reverse synchronisation matter: who issues the command, what the operator sees, and how a double check-in mark is excluded.

The backup must not be switched on arbitrarily by each desk. Uncoordinated local decisions create several versions of the truth. One lead decides on the mode, and the drill log records the time, reason and scope.

Contractor's report after the test run

The report must show the load actually generated and the result of each business operation. Constraints and those responsible for fixes are listed separately. A single average-latency chart is not enough.

The client needs a time-based profile, the printing status and how the backup performed. For critical defects, the result of a re-run using the original scenario is added.

The report includes:

• the version of the system and scenario;
• the version of the test data and hardware;
• the planned profile of operation start times;
• the profile actually generated;
• the results of each individual operation;
• errors and timeouts;
• "Too Many Requests" responses and retry behaviour;
• dropped_iterations and generator resources;
• total service time at the workstation;
• the print queue and cases of re-issuance;
• the result of failover to backup and recovery;
• the list of defects, owners and re-check criteria.

We link each defect to a reproducible scenario. The card retains the original conditions and the sequence of steps. It also states the expected result and what the team saw during the run.

To continue work, the impact, a temporary measure and an owner are recorded. The overall approach can be checked against the event incident log. Before the venue opens, defects are tracked separately from the event's working log.

A message saying "fixed" does not close an issue. The team repeats the same scenario under comparable initial conditions. If the result has changed, a new PASS appears in the report. If not, the defect remains open or is accepted as an explicitly agreed constraint.

Acceptance checklist for the client

You need a short list of clear confirmations, not access to every technical schedule. Before the rehearsal is signed off, check that the arrival profile has been reproduced, that edge cases did not stop the main flow, and that the backup is actually enabled. Assign an owner for each critical defect, and after it is fixed run a repeat test with the result recorded.

1. Arrival windows, entrances and the set of operations are described.
2. A baseline run of each route is completed before peak load.
3. Expected flow and a sudden spike are tested separately.
4. Actual throughput matches the plan, or any discrepancy is explained.
5. A successful QR ends with a single correct check-in.
6. A retry after a timeout does not create a duplicate.
7. Printing has been tested on real printers and consumables.
8. Manual cases go to a separate line and do not block the main flow.
9. Operators see clear statuses and the next action.
10. Synthetic data with restricted access has been used.
11. Dependency failure and recovery have been practised for real.
12. Each critical defect has been re-checked after the fix.

An on-site rehearsal is best built on the same principles as a technical event rehearsal: a scenario, an observable result, an owner for each issue, and a re-check. The difference is in focus — here the whole team looks only at the registration loop and its dependencies.

Acceptance should cover the guest's entire journey under real flow, during a failure and after recovery. A separate scanner or form does not give the full picture.

Sources

• Grafana k6: types of load testing
• Grafana k6: threshold criteria
• Grafana k6: dropped iterations
• Microsoft Azure Architecture Center: Retry Storm antipattern
• Microsoft Azure Architecture Center: Retry pattern
• Zebra DataWedge: barcode input and feedback
• GS1: quality and readability guide for two-dimensional codes
• IETF RFC 6585: HTTP 429 Too Many Requests
• W3C WCAG 2.2: Status Messages
• Federal Law No. 152-FZ: principles of personal data processing