text
Browser input
    ↓
Authenticated HTTP or realtime session
    ↓
Server-side identity and authorization checks
    ↓
Validated world action
    ↓
Persistent or realtime state update
Client state can still improve the user experience, but it is no longer treated as authoritative security evidence.
2. Realtime access tokens
We introduced a dedicated token endpoint for the realtime subsystem.
An authenticated application session can request a short-lived realtime token. The token contains only the minimum information required by the gateway, such as:
- user identifier;
- authorized role;
- optional public username;
- correlation identifier;
- expiration time.
The response also describes the supported connection contract:
{
  "success": true,
  "expiresInSeconds": 300,
  "socketPath": "/realtime",
  "transports": ["websocket", "polling"],
  "namespaces": [
    "user:{id}",
    "community:{id}",
    "session:{id}"
  ]
}
The correlation identifier lets us connect an HTTP request, token-minting operation, socket connection, and later operational events without exposing sensitive application data.
3. Authorized realtime channels
Realtime communication is organized around explicit channel families:
user:{id}
community:{id}
session:{id}
These channels are not arbitrary rooms that a client can join freely.
The server validates whether the authenticated user may enter the requested channel. This is essential for preventing:
- cross-user subscription;
- unauthorized community access;
- session impersonation;
- client-generated room escalation;
- accidental data leakage between realtime contexts.
We are also separating connection authorization from application events. Establishing a socket connection does not automatically authorize every action that may travel through it.
4. Redis-backed distributed presence
A single-process memory map is useful during local development, but it is not sufficient for a horizontally scaled realtime service.
When multiple application instances are running, each instance sees only its own connected users. A reconnect or deployment can also destroy local presence state.
We therefore implemented a Redis-backed presence store.
Redis keeps short-lived connection records for users inside community and session channels. The implementation supports:
- adding a connection;
- refreshing its expiration;
- removing it during disconnection;
- listing active members;
- handling multiple sockets belonging to the same user;
- pruning expired records;
- detecting the first and last active connection.
Presence data uses a TTL. Stale sockets eventually disappear even when the application does not receive a clean disconnect event.
The service retains a local fallback to avoid completely breaking realtime behavior during a Redis incident. However, that fallback is considered degraded mode—not production-ready distributed presence.
5. Redis failure handling
Redis operations are wrapped with explicit failure handling.
When Redis initialization or an established operation fails, the service:
1. records an aggregate Redis failure;
2. emits a structured operational event;
3. invalidates the failed shared client;
4. falls back locally where permitted;
5. exposes the degraded state through readiness.
We deliberately avoid returning Redis connection strings, internal exception messages, usernames, or infrastructure details to public clients.
Operational errors are represented through safe categories such as:
{
  "event": "redis_presence_failure",
  "operation": "health",
  "status": "local_fallback",
  "mode": "local-fallback",
  "reason": "redis_error"
}
6. Distributed rate limiting
Metaverse actions and realtime endpoints need protection against abuse, spam, and accidental request storms.
Local counters are insufficient when traffic reaches multiple server instances, so we developed a distributed rate-limiting path using Redis.
The rate-limiting architecture is designed to support:
- authenticated user limits;
- guest or anonymous limits;
- action-specific policies;
- shared counters across instances;
- explicit retry metadata;
- privacy-safe operational metrics;
- controlled degraded behavior.
Rate limiting is part of the server-side authorization boundary. A client cannot reset its allowance by refreshing the page or connecting to a different application instance.
7. Privacy-safe observability
Operational visibility is necessary, but observability must not become a second surveillance system.
The realtime metrics endpoint is restricted to administrators and exposes aggregate counters rather than individual user activity.
Current metrics can describe behavior such as:
- connection attempts;
- successful connections;
- authorization failures;
- active connection changes;
- Redis failures;
- rate-limit decisions;
- service degradation.
The endpoint does not return raw tokens, Redis URLs, database credentials, private messages, or individual browsing histories.
A simplified response follows this pattern:
{
  "success": true,
  "privacy": "aggregate-only",
  "counters": {
    "connectionAttempts": 42,
    "connectionSuccesses": 40,
    "redisFailures": 0
  }
}
The response uses Cache-Control: no-store so operational data is not retained by shared caches.
8. A real production-readiness endpoint
We added a public readiness endpoint:
GET /api/realtime/health
Its purpose is different from a generic “the process is running” check.
The endpoint verifies whether the dependencies required by the realtime subsystem are actually operational:
- Express router;
- MongoDB connection;
- Redis connection.
A healthy response follows this contract:
{
  "success": true,
  "service": "myzubster-realtime",
  "status": "ready",
  "checks": {
    "router": "ready",
    "mongodb": "connected",
    "redis": "connected"
  },
  "timestamp": "2026-10-23T00:00:00.000Z"
}
If MongoDB or Redis is unavailable, the endpoint returns HTTP 503:
{
  "success": false,
  "service": "myzubster-realtime",
  "status": "degraded",
  "checks": {
    "router": "ready",
    "mongodb": "connected",
    "redis": "disconnected"
  }
}
Readiness therefore means more than “the route exists.” It means the service can currently use its required durable and distributed infrastructure.
9. Reusing the shared Redis client
The readiness endpoint does not create a separate Redis implementation.
It uses the same shared Redis client used by the presence store. This reduces the risk of reporting a healthy dependency through one connection while the application is using another broken connection.
The readiness function:
1. checks whether REDIS_URL is configured;
2. initializes or reuses the shared client;
3. sends PING;
4. returns a normalized status;
5. invalidates the client after a failed ping;
6. records the failure through the existing observability service.
Conceptually:
async function redisReadiness() {
  if (!redisConfigured()) {
    return { ready: false, status: "not_configured" };
  }

  const client = await getRedis();

  if (!client) {
    return { ready: false, status: "disconnected" };
  }

  try {
    await client.ping();
    return { ready: true, status: "connected" };
  } catch (error) {
    recordRedisFailure(error);
    invalidateRedisClient(client);

    return { ready: false, status: "disconnected" };
  }
}
10. Isolated Preview infrastructure
We did not reuse Production database credentials for branch deployments.
Instead, the Vercel Preview environment was connected to isolated resources:
- a dedicated MongoDB Preview database;
- a scoped MongoDB Preview user;
- a Redis resource connected through REDIS_URL;
- environment variables restricted to Preview.
This gives us a safer environment for testing readiness, presence, failure modes, and migrations.
The boundary is explicit:
Pull request branch
    ↓
Vercel Preview deployment
    ↓
Preview-only MongoDB
    ↓
Preview-only Redis
Production secrets were not copied into the branch environment, and Production was not changed during this phase.
11. Automated verification
We added tests at two levels.
Presence-store tests
The Redis presence tests verify that the service:
- reports Redis as connected after a successful ping;
- reports it as disconnected after a failed ping;
- records an alertable Redis failure;
- falls back locally when connection initialization fails;
- falls back when an established Redis operation fails.
HTTP route tests
The realtime route tests verify:
- HTTP 200 when MongoDB and Redis are ready;
- HTTP 503 when MongoDB is disconnected;
- HTTP 503 when Redis is disconnected;
- the presence of the expected readiness fields;
- Cache-Control: no-store;
- the absence of sensitive values;
- administrator-only access to aggregate metrics;
- denial of metrics access to regular users.
The main CI workflow completed successfully, including:
- backend lint;
- backend unit tests;
- frontend unit tests;
- backend build;
- frontend build;
- artifact generation.
The Seller Free policy regression workflow also passed, and the Continuous Evidence Gate produced a retained evidence artifact.
12. Current pull-request status
The readiness work is tracked in a Draft pull request.
The latest implementation includes:
- Redis readiness in the shared presence service;
- Redis gating in the public health endpoint;
- MongoDB and Redis degradation behavior;
- unit and route-level tests;
- successful Preview deployment.
The pull request remains Draft intentionally.
We have not merged it and have not performed a Production rollout.
13. The current security blocker
The latest security audit detected two dependency advisories:
- one high-severity vulnerability;
- one moderate-severity vulnerability.
The affected package is ip-address <= 10.7.3, and an updated version is available.
This dependency issue is separate from the Redis readiness implementation, but it is still a release gate. The lockfile and the transitive dependency path must be reviewed and updated in a focused security change.
We will not describe the branch as release-ready while a high-severity dependency audit is failing.
14. What is still missing
The core realtime foundation is substantially stronger, but MYZ-83 is not complete.
The remaining work includes the following.
Dependency remediation
Upgrade the vulnerable dependency path, regenerate the lockfile, rerun the complete audit, and verify that the change does not break network-address handling.
Load baseline
Measure the realtime system under repeatable workloads:
- concurrent socket connections;
- connection and reconnection bursts;
- channel joins and leaves;
- presence refresh operations;
- distributed rate-limit operations;
- token issuance;
- HTTP and socket latency;
- MongoDB and Redis resource consumption.
The result must include reproducible commands, environment information, and retained metrics.
Redis restart drill
We need to demonstrate what happens when Redis becomes unavailable and later returns:
Redis healthy
    ↓
Redis interrupted
    ↓
Readiness becomes degraded
    ↓
Failures are counted
    ↓
Local fallback is bounded
    ↓
Redis reconnects
    ↓
Readiness returns to ready
MongoDB restart drill
The same operational evidence is required for MongoDB:
- health transition;
- connection retry behavior;
- public response safety;
- recovery time;
- absence of credential leakage;
- final healthy state.
Multi-instance validation
Distributed presence and rate limiting must be tested with multiple application instances. A single-instance test cannot prove that Redis-backed coordination behaves correctly across replicas.
Reconnection behavior
We still need repeatable tests for:
- short network interruptions;
- token expiration;
- reconnect storms;
- duplicate sockets;
- stale presence cleanup;
- retry backoff;
- client state restoration.
Production smoke test
Production verification will happen only after:
1. security remediation;
2. completed review;
3. explicit merge authorization;
4. an approved deployment;
5. confirmation that the correct Production resources are configured.
No Production change should be inferred from the successful Preview work.
15. What comes after reliability
Once the operational foundation is accepted, we can continue with higher-level metaverse features:
- richer shared-world interactions;
- realtime community events;
- persistent avatars and progression;
- WebXR exploration;
- spatial interfaces;
- collaborative missions;
- verified contributor identities;
- connections between the Metaverse and MyZubster Knowledge;
- development requests linked to GitHub contributions;
- community-governed experiences;
- optional reward and bounty bridges backed by verifiable evidence.
The sequence matters.
WebXR and visual features are valuable, but authentication, authorization, abuse protection, distributed state, and recovery behavior must come first.
Conclusion
The latest MyZubster Metaverse work is primarily about trustworthiness.
We moved closer to a system where:
- identities are derived from authenticated sessions;
- world actions are authorized by the server;
- realtime channels have explicit access rules;
- presence and rate limits can work across multiple instances;
- Redis and MongoDB are part of the readiness contract;
- operational metrics remain aggregate and privacy-safe;
- Preview infrastructure is isolated from Production;
- CI produces reproducible technical evidence;
- known security failures remain visible instead of being hidden.
The Metaverse is not production-complete yet, but its foundation is becoming measurable, testable, and independently reviewable.
That is the kind of progress we want: not unsupported claims, but small engineering steps backed by code, tests, deployments, and evidence.
Project links
- GitHub: https://github.com/danieldirimini-myzubster/myzubster
- Metaverse: https://www.myzubster.com/metaverse
- Realtime readiness PR: https://github.com/danieldirimini-myzubster/myzubster/pull/40
- MYZ-83 roadmap issue: https://linear.app/myzubster/issue/MYZ-83/b6-realtime-observability-reliability-and-load-tests