On the local node
- Live room events and presence work while the shared process and local network are healthy.
- Applications retain durable records outside the in-memory gateway.
Wizaya Server Suite
PBB Realtime
One shared local WebSocket gateway for live room events, presence, and approved application updates on a node.
What it is
A service in the local-node foundation
Integrated · Pilot-ready foundation
Baseline node service
PBB Realtime gives participating local applications a shared WebSocket process instead of running an independent real-time server for every module. It carries authorized room events and presence within the node.
Room membership and presence are held in process memory. Durable application truth remains in each owning service, so process restart and multi-node continuity require explicit handling outside this gateway.
Node role
What it contributes
Provides the local low-latency event path for participating applications while leaving durable records and workflow state with their authoritative services.
Service behavior
Local operation and connectivity
Across a route
- The confirmed foundation is one shared process per node, not a cross-node event fabric.
- Restart can clear in-memory rooms and presence even when durable application records remain intact.
Confirmed current integration
Modules with verified service paths
Only module integrations confirmed in the current implementation are listed here. Planned packaging, architectural relationships, and unverified paths are excluded.
Deployment placement
Where it fits
Baseline deployment
Barangay node; Local command node; Daily-apps node
Hardware, power, connectivity, training, travel, and field logistics remain deployment-specific.Operations and security
Boundaries operators must preserve
Operational considerations
- Supervise the process and verify application reconnect behavior after restart.
- Measure concurrent connections and event volume on representative pilot hardware.
Security boundary
- Authorize room joins and event publication at the application boundary.
- Do not place authoritative durable records only in process memory.
Practical questions
Frequently asked questions
Why use one shared gateway per node?
One shared service avoids running separate copies for every app and gives local apps one managed way to send live updates.
Are room events a durable system of record?
No. Live room and online-status updates are temporary. Each app must save any important records in its own permanent storage.
What happens when Realtime restarts?
Users and apps must reconnect, and live room or online-status information may need to be rebuilt. Information already saved by each app remains available.
Does it broadcast automatically between nodes?
No. Realtime serves its own local node. It does not automatically send live updates to every other PBB node.
Who may publish or join a room?
Each participating app must confirm who the user is and what they are allowed to do before letting them join a room or send updates.
Status and readiness
Integrated
A shared local gateway and participating module event paths are implemented for node-level operation.
Remaining hardening work
- Finalize capacity limits and restart behavior for pilot hardware.
- Document room authorization contracts for every publisher and subscriber.
- Define any future multi-process or multi-node scaling before claiming it.
Companion services
Related infrastructure
Broader platform context
Architecturally related modules
These relationships provide context and do not assert a confirmed current service integration. Verified integration paths appear in the earlier confirmed-integration list.
Briefing and pilot discussion
Discuss PBB Realtime in a local PBB deployment
Explore how a local-node deployment could support practical service continuity in your community.