Cache channels

A cache channel remembers the last triggered event, and sends this as the first event to new subscribers.

When an event is triggered on a cache channel, Pusher Channels caches this event. Then when a client subscribes to a cache channel, if a cached value exists, it’s sent to the client as the first event on that channel. This behavior helps developers provide the initial state without adding additional logic to fetch it from elsewhere.

Cache channels must be prefixed with cache- . Refer to Channel naming conventions.

Private cache channel subscriptions must be authorized. Refer to Authorizing users.

∞ Subscribe

var cacheChannel = pusher.subscribe(cacheChannelName);

let cacheChannel = pusher.subscribe(channelName: "cache-location")

var cacheChannel = Echo.join(cacheChannelName);

∞ Unsubscribe

Refer to unsubscribing from channels.

∞ Events

Refer to Binding to events for general information about how to bind to events on a channel object.

∞ Handling cache misses

Cache channel is a feature which can be added to public, private, and presence channels. All its behaviors are similar to regular channels. In addition to the fact that a cache channel remembers the last triggered event, it provides two ways for developers to deal with cache misses.

∞ cache_miss webhook event

When a client subscribes to a cache channel and there is no value available, Pusher Channels will notify your server by sending a cache_miss event to your webhook destination. When your server receives a cache_miss webhook, you can decide to trigger a new event on this channel. It will re-populate the cache.

Refer to the Cache_miss webhooks for more information on how you can configure this on your dashboard.

∞ pusher:cache_miss client event

In addition to the webhook event, the client can also use the event binding feature to subscribe to pusher:cache_miss event. This can be used by the client to request your server to get the initial data.

∞ pusher:cache_missEvent

channel.bind("pusher:cache_miss", () => {
    fetch('/trigger/car-location-123');
});

Refer to Events for more information on how you can use events.

Which approach is better? The answer depends on your implementation. In most scenarios, relying on the webhook event is more efficient. Because Pusher handles de-duplication when multiple clients are subscribed to an empty channel. So your server does not have to deal with requests per client when they subscribe to a channel with empty cache.

∞ FAQ

∞ How to determine cache age?

We do not add any attribute like age to your messages. You can add a timestamp attribute to your message if it is important for you to track that.

∞ How long does the message stay in cache?

The time to live (TTL) of an event stored in cache is up to 30 minutes. If you do not publish any event, the cached event expires after TTL has elapsed. > NOTE: TTL is up to 30 minutes. This means that in some cases, cache messages might expire sooner.

∞ Where is data stored?

Cached messages are temporarily stored in memory in the same cluster you selected for your application. Pusher does not create a backup or a snapshot of this data. And we do not distribute it to other regions. Refer to Cluster configuration to find out how you can comply with data protection regulations when using Pusher Channels.

∞ Can I retrieve the cached data from my application?

Yes. You can query the cached data from the HTTP API. The response contains the data as well as the remaining time to live of the cached message. Check the Channel Information section on the HTTP API documentation page.

∞ Are client events also supported?

No, client events are not currently supported. You can use client events in cache channels like regular channels, but we do not cache client events. If you find this feature useful for client events, we’d love to hear about it. Contact our support team.