01
Request arrives at the API endpoint
Your backend sends POST /api/events with the app key, channel name, event type, and JSON payload.
Architecture
The pipeline stays legible at every stage: request intake, persistence, queueing, signing, and websocket fan-out.
Step flow
01
Your backend sends POST /api/events with the app key, channel name, event type, and JSON payload.
02
Laravel validates every field, resolves the app by key, and can reject invalid or rate-limited traffic immediately.
03
The payload is persisted for auditing, debugging, replay workflows, and operational analysis.
04
Publish the event metadata to Redis so the system can observe and react in real time.
05
A queue job handles the expensive delivery path so the API can respond with 202 Accepted quickly.
06
The outgoing request is HMAC-signed and sent to the internal Reverb event endpoint with the payload attached.
07
Reverb matches the app and channel, then pushes the event to subscribed WebSocket clients instantly.
Map
This layout keeps the async handoff visible, which matters when diagnosing slow delivery or queue bottlenecks.
Backend Service
│
├─→ POST /api/events
│
▼
Laravel API (Validation)
│
├─→ Event saved to DB
├─→ Publish to Redis pub/sub
├─→ Dispatch queue job
│
▼ (Async)
Queue Worker
│
├─→ HMAC sign request
├─→ POST to Reverb /apps/{id}/events
│
▼
Reverb WebSocket Server
│
├─→ Match clients (app_key + channel)
├─→ Broadcast via WebSocket
│
▼
Frontend Clients
│
└─→ Receive event in real-time
Concepts
Each app has a distinct id, public key, and private secret. Only the backend ever uses the secret.
Channels define who should listen so subscriptions can stay focused and low-noise.
Use semantic event names such as order.created or message.sent so consumers remain clear and predictable.
Every event carries JSON data, making the integration language-agnostic and easy to inspect.
Build from understanding
Once the flow is clear, the integration is straightforward: create the app, copy the key, and send the first event.