Device Monitoring System
Devices send heartbeats. A background monitor marks the silent ones OFFLINE and pushes the change to a live dashboard.
- Category
- Realtime backend system
- Stack
- Go
- Gin
- PostgreSQL
- WebSocket
- JWT
- Docker
- Docker Compose
- Next.js
- TypeScript
- Source
- shiinobu/device-monitoring-system
Overview
A monitoring system that tracks device availability. Devices report in with periodic heartbeats, a background process finds the ones that went quiet, and the dashboard updates over WebSocket without a page refresh.
At a glance
- 10s device heartbeat interval
- 5s background monitoring interval
- 30s offline detection threshold
- WebSocket DEVICE_STATUS_CHANGED events
- Handler → Service → Repository architecture
- PostgreSQL connection pooling
- Concurrent multi-device simulation
- GitHub Actions CI validation
Problem and approach
Problem
Device monitoring that relies on manual refreshes or polling makes it hard to notice failures and slow to show status changes.
Approach
Devices report their own activity with heartbeats. A background monitor spots missing heartbeats and sets the device to OFFLINE, and WebSocket events carry the change to connected dashboards in realtime.
Architecture
Devices or simulators send heartbeat requests to the Go backend. The backend stores activity in PostgreSQL while a background monitor evaluates heartbeat timeouts. Status changes are then broadcast over WebSocket to the Next.js dashboard.
Device / Simulator
Sends a heartbeat request every 10 seconds.
Go backend
Authenticates requests, applies business logic, stores state and emits realtime events.
HTTP heartbeat
PostgreSQL
Stores device information, heartbeat activity and monitoring state.
SQL
Background monitor
Checks heartbeat activity every 5 seconds and finds devices past the offline threshold.
every 5 s
WebSocket
Broadcasts status changes to connected dashboard clients.
DEVICE_STATUS_CHANGED
Next.js dashboard
Shows the current status of each device and updates when an event arrives.
WebSocket
How it works
A simulation of the heartbeat logic in my Device Monitoring System. One tick is one 10 s heartbeat, played at 0.7 s. A device with three missed ticks (30 s) is marked OFFLINE.
- Device sends a heartbeat every 10 seconds.
- The backend records the latest heartbeat activity.
- A background monitor checks device activity every 5 seconds.
- A device is considered offline when no heartbeat is received for more than 30 seconds.
- The backend updates the device status.
- A DEVICE_STATUS_CHANGED event is broadcast through WebSocket.
- Connected dashboards update the device status without a page refresh.
Implementation
- Heartbeat processing
- Devices send heartbeat requests to the Go backend. The latest activity timestamp is stored so the monitor can tell whether a device is still active.
- Background monitoring
- A background process compares heartbeat activity against the configured timeout and changes the device status when the threshold is exceeded.
- Realtime broadcasting
- When a status changes, the backend broadcasts a DEVICE_STATUS_CHANGED event over WebSocket so connected dashboards update immediately.
- Layered backend
- HTTP handlers, business services and database repositories are separate, so transport, logic and persistence stay isolated.
- Authentication
- JWT protects backend operations, and passwords are handled with bcrypt.
Screens
Notes
Challenges
- Designing reliable heartbeat timeout detection
- Synchronizing background monitoring with database state
- Broadcasting device status changes through WebSocket
- Keeping HTTP handlers, services and repositories separate
- Handling multiple simulated devices concurrently
Status
Runs locally with Docker Compose. A five-device simulator generates heartbeats, so the ONLINE to OFFLINE flow can be watched without real hardware.
Next project
Disbursement API