WebSocket Streaming

Acceso’s real-time systems are designed for applications that require low-latency data delivery without relying on high-frequency polling. This layer enables event-driven architectures through persistent streams and push-based notifications.

The real-time stack integrates directly with Acceso’s internal services while maintaining strict isolation from core request handling paths.

---

WebSocket Streaming

WebSocket streaming provides continuous, bidirectional communication channels for live data delivery. This is intended for dashboards, monitoring systems, trading interfaces, and automation agents that require immediate updates.

WebSockets optimize for low latency. They do not replace REST for authoritative reads or historical backfills.

---

Typical lifecycle

1

Connect

Open a persistent connection to the WebSocket gateway.

Keep connection creation fast. Avoid doing heavy work on connect.

2

Authenticate

Authentication is performed during connection initialization using the same API key model as REST APIs.

Each connection is bound to a specific API key.

3

Subscribe

After the connection is established, subscribe to one or more channels.

Subscriptions are explicit. No data is streamed until you subscribe.

4

Consume + recover

Consume messages continuously. Plan for disconnects.

On reconnect:

• Re-authenticate

• Re-subscribe

• Backfill gaps via REST APIs if needed

---

Connection model

Clients establish persistent connections to the WebSocket gateway. Authentication is performed during connection initialization using the same API key model as REST APIs.

Each connection is:

• Stateless with respect to business logic

• Bound to a specific API key

• Subject to tier-based connection limits

Idle connections are terminated automatically to conserve resources.

---

Subscription channels

WebSocket streams are organized into logical channels. Clients explicitly subscribe to channels after connection establishment.

Supported channel categories include:

• Token price updates

• Market activity streams

• Wallet activity monitoring

• DeFi protocol events

Each channel delivers normalized messages with consistent schemas regardless of upstream data source.

Example: a minimal subscription shape (pseudocode)

{
  "action": "subscribe",
  "channel": "token_price_updates",
  "params": {
    "symbol": "SOL"
  }
}

---

Message delivery guarantees

WebSocket streams are optimized for low latency rather than guaranteed delivery. Messages represent current state changes and should not be treated as authoritative historical records.

Clients are expected to:

• Handle reconnections gracefully

• Re-subscribe on reconnect

• Use REST APIs for backfilling missed data

---

Recommended client behavior

Manage concurrency and memory

• Use a bounded queue between the socket and your business logic.

• Drop or coalesce messages when your UI cannot keep up.

• Prefer “latest state” processing for high-frequency channels.

Handle disconnects predictably

• Retry with backoff. Add jitter to avoid synchronized reconnect storms.

• Treat the first payload after reconnect as “fresh state,” not a delta stream.

Do not assume “exactly once” or “in-order” delivery. Design consumers to be resilient.