Real-time HRMS architecture: a worked example with SWOT HR

A real-time HRMS architecture keeps two kinds of work apart: events that people need to see at once, such as a punch-in or a leave approval, and work that must be deliberate, such as a monthly payroll run. The events travel over a push channel to the dashboards that are allowed to see them; the payroll run reads approved records from the database and leaves an audit trail. This post is for engineers and technical HR leads designing or assessing an HRMS. It walks through the data model, live attendance, payroll, roles and integrations, using the documented design of SWOT HR v2.5 as the worked example.

A real-time HRMS is a human resources management system in which attendance, leave and approval changes reach the relevant employees, managers and HR staff as they happen, while the database stays the single system of record for every employee, balance and payroll run.

Which HR events actually need to be real time?

Start with a list of events, not a technology. For each one, write down who should see it, the acceptable delay and what happens if a notification is missed. Most HR data falls into three groups.

Event	Who needs it	Delivery	System of record
Punch in, punch out, break	Employee, reporting manager	Push to live dashboards	Attendance log in the database
Leave applied, approved, rejected	Employee, manager, HR	Push plus email and in-app alert	Leave balances table
Announcement, holiday, anniversary	Everyone	Push to dashboards	Announcements table
Payroll run, payslip	HR admin, then each employee	Batch run, then self-service portal	Payroll runs and payslips
Salary change, attendance override	HR admin, auditor	Logged, no push needed	Append-only audit log

In SWOT HR, punches and leave status changes are pushed to every connected team dashboard over WebSocket pub/sub channels, according to the architecture documentation. Payroll is not pushed: it is a monthly run started by an HR administrator.

The data model in a real-time HRMS architecture

Live updates are only as good as the records behind them. SWOT HR uses PostgreSQL 16 with the Prisma ORM, and its schema enforces relational integrity across organisations, departments, roles, shifts, leave balances, payroll runs and audit logs. Each employee is provisioned with a reporting manager, cost centre, salary template and shift group, which is what lets approvals route and payroll calculate without manual lookups.

Two design rules follow. First, every live event should correspond to a committed database change, so a dashboard that reconnects can reload state rather than trust the events it missed. Second, policy belongs in data: shift timings, grace periods, half-day thresholds and leave entitlements are configuration, not code. SWOT HR’s user guide, for example, sets a 15-minute grace period on its sample shifts and marks a day as a half day below 4.5 effective hours.

How real-time attendance works

A punch is the busiest write in any HRMS, because a whole shift starts within minutes. SWOT HR records attendance through the web portal, a mobile app with geofencing or a biometric sync, depending on shift policy. Breaks are tracked separately so effective hours stay accurate, and at punch-out the system works out regular hours and approved overtime.

The documented topology puts an attendance real-time processor in the Express and TypeScript backend cluster, with Redis 7 holding sessions and carrying pub/sub broadcasts. The WebSocket protocol gives browser applications two-way communication without opening multiple HTTP connections or long polling. Redis documents its pub/sub as at-most-once delivery: a message missed during a network disconnect is lost. That is acceptable only because the punch itself is already stored in PostgreSQL.

How should payroll runs be designed?

Payroll is long-running, money-moving work, so it should not share a code path with interactive requests. SWOT HR runs payroll as a one-click monthly computation in an automated payroll calculation service, taking account of unpaid leave, provident fund caps, professional tax and TDS. Employees then see encrypted payslips, year-to-date tax forecasts, Form 16 and provident fund breakdowns in the self-service portal.

Whatever HRMS you build or buy, a payroll run needs these properties:

1. Fixed inputs: the run reads approved attendance and leave for a closed period.
2. Safe retries: repeating a run does not duplicate a payment or a payslip.
3. A visible status and actionable errors for authorised staff only.
4. An audit entry for every salary change, override and rerun.
5. A tested restore path. SWOT HR takes hourly PostgreSQL snapshots with WAL archiving to encrypted object storage; PostgreSQL’s own documentation explains how continuous archiving allows a restore to any point since the base backup.

Roles and permissions on every channel

Role-based access control is the usual model for HR because permissions follow the job, not the person. SWOT HR defines four roles and checks them in a JWT authentication and RBAC validation engine in the backend.

Module	Employee	Manager	HR admin	Auditor
Attendance	Punch and own log	Team approvals	Full override	Read-only
Leave	Apply, see balances	Approve or reject	Set the policy	Read-only
Payroll	Own payslip	Own payslip	Run and disbursal	Read-only
Audit log	No	No	View and export	View and export

The architectural point is that a WebSocket subscription is an API call too. A manager’s dashboard should only receive events for direct reports, and the check has to happen when the channel is joined, not just at sign-in. SWOT HR backs this with short-lived 15-minute access tokens, single-use refresh tokens in HttpOnly cookies, TOTP multi-factor authentication and a rate limit of 100 requests a minute per IP. Enrolment is closed: HR administrators create every account.

SWOT HR: the executive dashboard.

Integrations and data protection

An HRMS sits between identity, devices and finance. SWOT HR documents single sign-on with Google Workspace, Microsoft 365 or Okta, biometric attendance sync, a REST API alongside the WebSocket channel, and backups to AWS S3 or Cloudflare R2. Sensitive fields (bank details, national IDs, salaries) are encrypted with AES-256-GCM at rest, traffic uses TLS 1.3, and passwords are hashed with bcrypt.

Check the network path before go-live. The SWOT HR FAQ notes that the AI assistant needs outbound WebSocket traffic on port 443 allowed through enterprise proxies, and the same applies to live dashboards. For a security view of who can reach the HR database itself, see the database security approach.

Validation checklist before rollout

• List each real-time event with its audience and acceptable delay.
• Confirm dashboards reload state from the database after a reconnect.
• Test a shift-start burst of punches with realistic headcount.
• Run payroll twice on the same period and confirm nothing duplicates.
• Join a live channel as each role and confirm what it can and cannot see.
• Restore the database from backup to a chosen point in time.
• Size the environment against the documented tiers: SWOT HR starts at 2 vCPU and 4 GB for up to 100 employees.

For how this design compares with suite, modular and SaaS approaches, read the HRMS architecture comparison; to score vendors, use the HRMS evaluation checklist.

Next steps

A real-time HRMS architecture pushes attendance and leave events to the right roles, keeps payroll as an audited batch run and treats the database as the record. To see SWOT HR’s version of this design with your own shifts and leave rules, book a demo.