Idempotent Attendance Check-In — Why It Matters at Scale

There is a class of HRM bug that costs companies real money and is invisible until month-end: an employee marks attendance, the UI confirms, and then somewhere downstream the record gets dropped. The day shows as absent. Payroll docks. The employee finds out two weeks later. Multiply by thousands of employees and the cost compounds quickly. The architectural fix is idempotency.

How the bug happens

Most attendance systems work roughly like this:

1. Employee opens the mobile app, presses "Mark Check-In".
2. App sends a request to the backend.
3. Backend writes the check-in event to the database.
4. Backend returns success.
5. App shows the green "checked in" UI.

At small scale, this works fine. At large scale, here is what can go wrong:

• Mobile flakiness. The phone loses signal between step 2 and step 4. The app retries. The backend may or may not have committed step 3. If retry creates a duplicate, the day is double-counted; if retry conflicts, neither attempt wins.
• Multi-source races. The employee marks attendance on biometric at the door at 9:00 AM, then opens the mobile app at 9:01 AM and the app silently re-marks them with a stale timestamp. The biometric event gets overwritten.
• Sync conflicts on offline-first apps. The app held the check-in offline for two hours. When connection returns, the sync runs in parallel with another sync, and one wins.
• Worker queue races. The check-in went into a background queue. The queue handler runs twice (retry semantics). Two records get written. The duplicate cleanup job picks one to delete and picks wrong.

The user-visible symptom is always the same: the UI said "checked in", but the timesheet says absent.

The idempotency fix

The architectural pattern that prevents all of these failure modes is idempotent check-in. The key insight: a check-in is not an "insert a row" operation. It is a "this employee was present on this day from this source" assertion. The same assertion can be repeated five times and it is still one assertion.

Zaffre HRM's attendance model:

1. Every check-in event has a stable composite key: (company, employee, day, source). Source is one of biometric / web / mobile / desktop.
2. The write is an upsert on that key. If the same key arrives twice, the second write is a no-op (or updates the timestamp to the earliest observed, depending on policy).
3. The event log is append-only. No application code can "drop" a check-in. The only way to remove a check-in is through an audited adjustment (which writes a counter-event, not a delete).
4. The attendance flag for the day is derived deterministically from the set of events for that (employee, day). Reading is a fold over the event log, not a separate writable state.

The result: a confirmed check-in cannot be silently dropped. Retries are safe. Multi-source events from biometric + mobile merge cleanly. Offline syncs cannot collide. The same code path serves 50 employees and 5000.

What this means for the customer

The day-to-day visible difference is small — when things work, idempotent and non-idempotent systems look identical. The difference shows up at month-end:

• The "I checked in but my timesheet says I was absent" support tickets disappear.
• The HR team stops doing the manual reconciliation pass on every payroll cycle.
• The dashboard numbers match reality.
• The audit trail is reliable; an auditor asking "show me all check-ins for this employee for this month" gets a deterministic answer.

For organizations with 500+ employees this saves real money every month. For organizations with 1000+ employees it is genuinely the difference between an HRM that works and one that does not.

How to evaluate this in a vendor

Ask the vendor: "if my employee's check-in is confirmed by the UI, can a downstream sync race drop it? Walk me through your idempotency model."

If the answer is hand-wavy ("we have retries", "we use queues"), the model is probably not idempotent. The right answer names the composite key, describes the upsert semantics and explains how the attendance flag is derived rather than written.

Zaffre HRM is built on this model. See the biometric attendance use case or book a technical demo if you want to walk the code paths.