Question

The MyZubster Metaverse has reached a new technical milestone.

We have merged a major realtime observability and reliability update into the main MyZubster repository.

Pull Request:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1042

Merged commit:
https://github.com/MyZubster-Ecosystem/myzubster/commit/57fa5be2c315cb9bf55bd306969291ea10ccf766

What we implemented

The new system introduces privacy-safe monitoring for the Socket.IO realtime gateway.

It can measure:

• active connections;
• connection and resume attempts;
• delivered and failed messages;
• notification delivery;
• Redis failures;
• queued operations;
• backpressure rejections;
• operation latency percentiles;
• SLO evaluations and alert candidates.

The telemetry does not include message content, authentication tokens, private keys, or raw user identifiers.

Controlled backpressure

Realtime systems can become unstable when they receive more work than they can process.

We added a bounded operation queue around critical Socket.IO operations.

When the system is temporarily busy, an operation can wait in the queue. If the configured capacity is reached, the client receives a retryable error instead of allowing unlimited memory consumption.

This gives us safer behavior during traffic bursts and measurable capacity limits.

Durable messaging

Messages and notifications are now stored before realtime delivery is attempted.

The new sequence is:

1. Validate the operation.
2. Save the message or notification.
3. Attempt Socket.IO delivery.
4. Record the delivery result.
5. Allow clients to recover stored information later.

A temporary socket or notification failure therefore does not destroy a message that was already saved successfully.

Redis recovery

Redis supports distributed presence when multiple realtime workers are running.

The presence layer now records Redis connection failures and can temporarily degrade to local in-memory presence.

This fallback keeps a single worker usable, while metrics clearly identify that distributed presence is unavailable.

Failed Redis clients are also invalidated so that future operations can reconnect.

Administrative metrics

We added an administrator-only endpoint:

GET /api/realtime/metrics

It provides aggregate metrics, latency information, SLO evaluations, and alert candidates.

The response is protected by authentication and uses Cache-Control: no-store.

Testing

The implementation includes tests covering:

• observability counters and latency;
• Redis degradation;
• notification durability;
• chat delivery failures;
• administrator authorization;
• connection bursts;
• message bursts and backpressure.

We also created two operational commands:

npm run metaverse:realtime-self-check

npm run metaverse:load-baseline

A local self-check successfully processed:

• 12 simultaneous connections;
• 48 messages;
• 44 queued operations;
• zero rejected operations;
• approximately 186 ms message p95 latency.

All modified JavaScript files passed syntax validation, and the 20 files uploaded to GitHub were verified against their remote hashes.

What the production check revealed

The Vercel deployment completed successfully, and the existing metaverse is online:

https://www.myzubster.com/metaverse

The metaverse health endpoint reports MongoDB as connected and the existing shared-polling transport as healthy:

https://www.myzubster.com/api/metaverse/health

However, the new realtime metrics endpoint is not publicly active yet.

The current Vercel deployment executes:

api/index.js → server.js

The persistent Socket.IO service is implemented in:

backend/src/index.js

This means that the code is merged, but the long-running realtime backend still needs its own production deployment.

Next infrastructure phase

The next step is to deploy the realtime backend on a persistent Node.js service with:

• MongoDB;
• Redis;
• a secure realtime token secret;
• WebSocket support;
• routing for /realtime;
• routing for /api/realtime/*;
• monitoring dashboards and alerting;
• Redis and worker restart tests;
• production load testing.

Vercel can continue serving the frontend and serverless APIs, while a persistent Node.js runtime handles Socket.IO traffic.

An important engineering lesson

A successful monorepo deployment does not necessarily mean that every service in the repository is running.

Testing the production URLs helped us discover the exact boundary between the Vercel application and the persistent realtime backend.

The code foundation is ready. The next objective is to connect it safely to the public MyZubster infrastructure.

Project links:

MyZubster Metaverse:
https://www.myzubster.com/metaverse

GitHub repository:
https://github.com/MyZubster-Ecosystem/myzubster

GitHub organization:
https://github.com/MyZubster-Ecosystem