The MyZubster Metaverse has reached another important technical milestone.
Our latest work focused on making the realtime infrastructure more observable, reliable, privacy-conscious, and ready for controlled load testing.
The implementation was merged into the main MyZubster repository:
What we built
The new implementation introduces a dedicated observability layer for the Socket.IO realtime gateway.
It tracks aggregate operational signals such as:
- active connections;
- connection and resume attempts;
- delivered and failed messages;
- notification delivery;
- Redis availability;
- queued operations;
- backpressure rejections;
- operation latency percentiles;
- service-level objective evaluations;
- alert candidates.
The telemetry is designed to be privacy-safe. Logs and metrics avoid exposing raw user identifiers, message content, authentication tokens, or private keys.
Where correlation is necessary, short hashed references are used instead of direct identifiers.
Bounded backpressure
Realtime systems can become unstable when traffic arrives faster than the server can process it.
To reduce this risk, we added a bounded operation gate around important Socket.IO operations.
When the system is busy, operations can wait briefly in a controlled queue. If the queue reaches its limit, the client receives a retryable response instead of allowing unlimited work to accumulate in memory.
This creates more predictable behavior during traffic bursts and provides measurable information for capacity planning.
Durable messages before live delivery
A realtime event should not be considered successful only because it was emitted through a socket.
The updated flow stores chat messages and notifications before attempting live delivery.
The sequence is now:
- Validate the request.
- Persist the message or notification.
- Attempt realtime delivery.
- Record delivery success or failure.
- Allow the client to recover the durable record later.
This prevents a temporary socket failure from deleting or invalidating information that was already stored successfully.
Notification delivery failures also no longer invalidate an already durable chat message.
Redis degradation strategy
Redis is used for distributed presence across multiple realtime workers.
The presence service now records Redis connection and operation failures and can temporarily fall back to local presence storage when Redis is unavailable.
The fallback keeps a single worker operational. However, it is reported clearly because local memory cannot provide consistent presence across multiple server instances.
The service also invalidates failed Redis connections so that later operations can attempt to reconnect.
Administrative metrics endpoint
We added an authenticated administrative endpoint:
GET /api/realtime/metrics
The endpoint is designed to return aggregate metrics, SLO evaluations, latency information, and alert candidates.
It is protected by authentication and administrator authorization. Its responses use:
Cache-Control: no-store
Once the persistent realtime service is deployed, unauthenticated users should receive an authorization error instead of operational data.
Tests and load baselines
The update includes tests covering:
- realtime observability;
- Redis failure and local fallback;
- notification durability;
- chat notification failures;
- administrative metrics authorization;
- Socket.IO connection bursts;
- message bursts and backpressure.
We also added two operational scripts:
npm run metaverse:realtime-self-check
npm run metaverse:load-baseline
The local self-check completed successfully with this sample result:
{
"success": true,
"baseline": {
"connections": 12,
"messages": 48,
"connectionDurationMs": 67,
"burstDurationMs": 192,
"messageP95Ms": 186,
"queuedOperations": 44,
"rejectedOperations": 0
}
}
All 15 modified JavaScript files passed syntax validation.
The 20 files published to GitHub were also compared with their remote Git blob hashes. All 20 matched their local source files.
The production check revealed an important gap
After merging the work, the Vercel production deployment completed successfully.
The public website and the existing metaverse are operational:
The health endpoint currently reports MongoDB as connected and the existing shared-polling transport as healthy.
However, the new realtime metrics endpoint currently returns:
Cannot GET /api/realtime/metrics
This production test exposed an architectural difference between the repository and the deployed runtime.
Vercel currently executes:
api/index.js → server.js
The Socket.IO server and its metrics router are mounted in:
backend/src/index.js
Therefore, the implementation is merged into the repository, but the persistent realtime backend is not yet connected to the public MyZubster domain.
This is an important distinction:
A successful deployment does not automatically mean that every service in a monorepo is running.
What comes next
The next infrastructure phase is to deploy backend/src/index.js on a persistent Node.js runtime capable of maintaining WebSocket connections.
The deployment will require:
- a persistent Node.js service;
- MongoDB connectivity;
- a production Redis instance;
- a secure realtime token secret;
- WebSocket support;
- routing for
/realtime; - routing for
/api/realtime/*; - an external metrics scraper and dashboard;
- Redis and worker restart drills;
- production load testing.
Vercel can continue serving the website and serverless APIs, while the persistent Node.js service handles Socket.IO traffic.
Why this matters
This work is not only about adding another endpoint.
It establishes the foundation for a metaverse where presence, chat, notifications, moderation, and collaborative sessions can be measured and recovered without compromising user privacy.
The production check also gave us something equally valuable: a precise picture of the remaining deployment boundary.
The code is merged. The local baseline is green. The next challenge is connecting the persistent realtime runtime to the public MyZubster infrastructure.
Top comments (0)