# Real-Time Updates

A modern store feels alive: the cart badge updates the instant you add an item,
stock counts tick down during a flash sale, the wishlist count changes without
a refresh. The platform delivers this with **Hotwire over ActionCable** — no
client-side framework required.

## How it works

The UI is server-rendered. Real-time updates are just **more server-rendered
HTML**, pushed to the browser over a WebSocket:

```
Something changes ──▶ background job ──▶ Turbo Stream broadcast
                                              │
                                              ▼
                                   <turbo-stream> patches the DOM
```

A `BroadcastCartUpdateJob` (or its inventory / wishlist / rating siblings)
renders the affected fragment and broadcasts it on an ActionCable channel. The
browser, subscribed via a Turbo Stream, splices the new HTML into place. The
server stays the single source of rendering truth — there is no duplicated
view logic in JavaScript.

## What updates live

- **Cart** — the header badge and cart summary, the moment an item is added or
  removed.
- **Inventory** — stock indicators, especially during [flash
  sales](/features/flash-sales/).
- **Wishlist** — the live count and shared-wishlist activity.
- **Product engagement** — ratings and comments as they arrive.
- **Admin** — dashboard figures that move without a reload.

These broadcasts run on **Sidekiq** rather than Solid Queue — see
[Background Jobs](/architecture/background-jobs/) — because the broadcast
firehose wants Redis throughput over transactional coupling.

## Web push

Real-time does not stop when the tab closes. A **Web Push** integration
(`WebPushService`, with VAPID keys and `push_subscriptions`) delivers browser
notifications — for example, a security alert on a new login — even when the
shopper is not on the site.

## Why not a SPA

A single-page app could do all of this, at the cost of a second rendering
codebase, a build pipeline, and state-sync bugs. Hotwire gets the same
perceived interactivity by treating the WebSocket as just another way to ship
the HTML the server already knows how to render. Less code, one source of
truth.

## Key files

| Concern | Files |
|---------|-------|
| Broadcasts | `BroadcastCartUpdateJob`, `BroadcastInventoryAlertJob`, `BroadcastWishlistRealtimeUpdateJob`, `OrderStatusBroadcastService` |
| Web push | `WebPushService`, `PushSubscription` |
| Transport | ActionCable channels, Turbo Streams |

Real-Time Updates

A modern store feels alive: the cart badge updates the instant you add an item, stock counts tick down during a flash sale, the wishlist count changes without a refresh. The platform delivers this with Hotwire over ActionCable — no client-side framework required.

How it works

The UI is server-rendered. Real-time updates are just more server-rendered HTML, pushed to the browser over a WebSocket:

Something changes ──▶ background job ──▶ Turbo Stream broadcast
                                              │
                                              ▼
                                   <turbo-stream> patches the DOM

A BroadcastCartUpdateJob (or its inventory / wishlist / rating siblings) renders the affected fragment and broadcasts it on an ActionCable channel. The browser, subscribed via a Turbo Stream, splices the new HTML into place. The server stays the single source of rendering truth — there is no duplicated view logic in JavaScript.

What updates live

Cart — the header badge and cart summary, the moment an item is added or removed.
Inventory — stock indicators, especially during flash sales.
Wishlist — the live count and shared-wishlist activity.
Product engagement — ratings and comments as they arrive.
Admin — dashboard figures that move without a reload.

These broadcasts run on Sidekiq rather than Solid Queue — see Background Jobs — because the broadcast firehose wants Redis throughput over transactional coupling.

Web push

Real-time does not stop when the tab closes. A Web Push integration (WebPushService, with VAPID keys and push_subscriptions) delivers browser notifications — for example, a security alert on a new login — even when the shopper is not on the site.

Why not a SPA

A single-page app could do all of this, at the cost of a second rendering codebase, a build pipeline, and state-sync bugs. Hotwire gets the same perceived interactivity by treating the WebSocket as just another way to ship the HTML the server already knows how to render. Less code, one source of truth.

Key files

Concern	Files
Broadcasts	`BroadcastCartUpdateJob`, `BroadcastInventoryAlertJob`, `BroadcastWishlistRealtimeUpdateJob`, `OrderStatusBroadcastService`
Web push	`WebPushService`, `PushSubscription`
Transport	ActionCable channels, Turbo Streams