Blog post cover image

Subscription Filters

Event-based systems are always nuanced. Generic message design for future flexibility or narrow scope to prioritise known requirements now.

With subscription filters, you can get a bit of both.

What are subscription filters?

Subscription filters are a mechanism in sailhouse to only care about specific events for a given subscription. When it comes to sending events, Sailhouse will check the shape of the event sent to see if it should be included for that subscription.

[[subscription]]
slug = "new-pro-user-notification"
topic = "new-users"
[subscriptions.filter]
path = "type"
value = "pro"

Effectively, they’re a declarative filter for your events. It cuts down on the potential noise from a subscription, and you can keep a generic topic scope if you need while fulfilling a basic requirement now.

Why not just filter in the application?

It saves on execution. A push subscription here will only be called when there is a match, reducing the number of HTTP calls to a given endpoint. For pull subscriptions, it reduces the number of events you’re pulling down. Saving bandwith, outbound acknowledgement for no-op events and removing the need for you to add boilerplate checks for events you’re recieving.

This lowers cost, allowing you to architect in a way where you get the benefits of a narrow-scope and the flexibility of generic events.

Use cases

Oh where to begin, some highlights:

  • High-volume events where you have a large number of subscriptions (e.g. new-users)
  • Allows implementation of small, isolated features without big up-stream changes to optimise cost/performance
  • A/B Testing and gradual roll out

The opportunity to filter in the event-layer gives huge technical freedom to teams of any size. A small solo engineer doesn’t have to think about the overheads of generic messaging while larger teams benefit from the autonomy given to each team by listening to what they need.

hello@sailhouse.devTerms of UsePrivacy PolicyFair Usage PolicyStatus