How Temp Chat Works (System Architecture)
Last Updated: September 13, 2026
This document outlines the technical architecture of HZ Chat and clarifies how data flows through the system.
HZ Chat is built as a session-based, real-time communication system designed for intentional user-created or user-shared chat sessions. Messages are transmitted through a WebSocket-based relay layer and are managed through a lifecycle-based synchronization model. The system does not maintain a permanent server-side message archive or traditional message history database.
File attachments are stored in object storage with enforced expiration rules. Upon expiration, files are permanently deleted and are not recoverable.
The architecture is intentionally optimized for real-time delivery, operational efficiency, and limited data retention. Core components include:
- Connection Manager (session lifecycle control)
- Room Manager (room lifecycle and participant coordination)
- Client Handler (real-time message relay)
- Ephemeral Storage Layer (short-lived file handling)
All components are designed to prioritize real-time delivery, privacy-focused synchronization, and controlled data lifecycle management over traditional centralized persistence.
System Architecture Topology
HZ Chat is built around a real-time relay architecture with local-first message history and temporary synchronization mechanisms.
Messages are processed for immediate delivery and are not stored in a permanent server-side message archive.
[ Client ]
│
▼ (HTTPS / WSS)
[ Cloudflare Edge Network ]
│
▼ (TLS termination + forwarding)
[ Nginx Gateway ]
│
▼
[ Go Application Node (Real-time Processing & Synchronization) ]
│
├── NATS Core (Message broadcast, memory-only)
├── Redis (Online state & quota control, persistence disabled)
├── PostgreSQL (Account & room metadata)
└── Cloudflare R2 (Temporary file storage, 24h lifecycle policy)
Under normal operating conditions, active message delivery is handled through the runtime memory of Go application nodes and NATS in-memory communication channels. Chat messages are not written to PostgreSQL or maintained as a permanent server-side message archive. For Fixed Rooms with history enabled, message synchronization may temporarily use server memory to cache synchronized message data and improve delivery efficiency between active participants.
Component Responsibilities
This section describes the role of each system component in the data flow and clarifies whether it involves message persistence.
Cloudflare Edge Network
- Acts as the global entry point for incoming traffic
- Terminates TLS connections and forwards requests to the origin server over HTTPS
- Provides DDoS protection, basic rate limiting, and network acceleration
HZ Chat does not configure Cloudflare to store or persist chat message content.
Cloudflare may generate short-term infrastructure logs (such as security or performance logs) in accordance with its platform-level policies and agreements.
Nginx Entry Layer
- Acts as a reverse proxy, routing incoming traffic to Go service nodes
- Handles basic access control and request forwarding
The server retains standard access logs for operational diagnostics and abuse prevention.
IP addresses recorded in logs are anonymized at the application layer:
- IPv4: the last octet is zeroed (e.g., 192.168.1.23 → 192.168.1.0)
- IPv6: the latter portion is truncated and compressed
Access logs do not contain chat message content.
Go Service Nodes
- Manage WebSocket session lifecycle
- Handle room lifecycle and active participant state
- Forward messages through real-time channels and process synchronization requests.
Active message delivery exists within in-memory runtime structures for real-time broadcasting. Synchronization requests may temporarily process or cache message data in memory without creating permanent server-side storage.
Structured error logs are recorded for operational stability and debugging purposes.
These logs do not include chat message content.
NATS Core
- Used for inter-node message broadcasting
- Operates in memory-only mode
- Disk storage is not enabled
NATS does not retain historical messages and is used solely for real-time distribution.
Redis
- Used for online presence tracking and rate limiting
- Persistence is disabled (RDB and AOF are not enabled)
Redis data exists only as runtime state.
PostgreSQL
- Stores account information
- Stores room metadata (e.g., room identifiers)
Chat messages are not stored in the database.
Cloudflare R2
- Used for temporary file storage (e.g., user-initiated uploads)
- Files follow a lifecycle policy for automatic deletion (currently 24 hours)
The file storage system is independent from the chat message processing pipeline.
Message Data Lifecycle
The core design principle of HZ Chat is:
Messages are delivered through real-time communication channels and managed through lifecycle-based synchronization rather than a centralized permanent message database.
Message Transmission Flow
- A user establishes a secure connection via HTTPS / WSS.
- The message reaches a Go service node.
- The message is immediately published to a NATS Core in-memory channel.
- Online members in the same room receive the message in real time through the NATS broadcast flow. For Fixed Rooms with message history enabled, clients may additionally store received messages locally and synchronize missing messages when required.
This entire process occurs in memory and does not trigger disk writes.
No Permanent Server-Side Message Archive
- Chat content is not written to PostgreSQL.
- Chat content is not written to Redis.
- Chat content is not written to log files.
- No permanent server-side historical message replicas are generated.
- Server restarts do not restore server-side message synchronization data or create access to previous messages that are not available through local storage or active synchronization sources.
If a server restarts unexpectedly, temporary server-side synchronization data is cleared. Messages stored locally by users or available through active synchronization sources may still be recovered.
This behavior is enforced by system design and is not configurable at the application level.
Temporary Room Session Expiration Mechanism
Temporary Room sessions are automatically terminated under the following conditions:
- All participants have been absent for more than 3 minutes.
- The room has been inactive for 30 minutes.
Once expiration is triggered:
- The in-memory room structure is destroyed.
- The associated NATS channel becomes inactive.
- Redis presence indexes expire.
- Temporary synchronization state related to the session is cleared.
Temporary server-side synchronization data becomes unrecoverable once the runtime state is cleared.
Data Classification and Storage Boundaries
| Data Type | Persisted | Storage Location | Description |
|---|---|---|---|
| Chat Messages | Conditional | Volatile Memory / IndexedDB / Temporary Server Cache | Messages are delivered through runtime memory. Temporary Rooms do not retain message history. History-enabled Fixed Rooms may store messages locally in the user’s browser and use temporary synchronization mechanisms when required. |
| WebSocket Message Payload | No | Volatile Memory | Not written to databases or log files |
| Presence State | No | Redis (persistence disabled) | Used only for runtime state coordination |
| Message Broadcast Channel | No | NATS Core (in-memory mode) | No disk storage enabled |
| Account Information | Yes | PostgreSQL | Username, hashed password, subscription tier, last login time, optional email |
| Room Metadata | Yes | PostgreSQL | Room identifier, creation time, expiration time |
| Temporary Files | Yes (max 24 hours) | Cloudflare R2 | User-initiated uploads, automatically deleted according to lifecycle policy |
| Access Logs | Yes (short-term retention) | Nginx | Contains anonymized IP addresses; does not include chat content |
| Application Error Logs | Yes (short-term retention) | Go service logs | Used for debugging and stability monitoring; does not include message bodies |
Design Trade-off: No End-to-End Encryption
HZ Chat uses HTTPS / WSS for transport-layer encryption but does not implement end-to-end encryption (E2EE).
This is a deliberate architectural decision.
E2EE introduces additional complexity, including:
- Client-side key generation and storage
- Multi-device key synchronization
- Key recovery challenges
- Reduced server-side operational control
Because the system does not maintain a permanent server-side message archive, message data availability is limited by active sessions, local storage boundaries, and temporary synchronization lifecycle.
The system is designed as a real-time communication utility rather than a private archival messaging platform.
The goal is to minimize long-term data exposure while maintaining operational simplicity and predictable behavior.
Version & Updates
This document reflects the current system architecture and data handling design of HZ Chat as of the effective date above.
If material changes are made to data categories, storage mechanisms, or retention policies, this document will be updated accordingly.
In the event of any inconsistency between this document and the Privacy Policy, the Privacy Policy shall prevail.
This document provides technical transparency and does not constitute a legal agreement.