Return to Blog
July 12, 2021
3 min read time

Two-Minute Tech Tuesdays - Varnish Broadcaster

Thijs Feryn
  • VHA
  • caching
  • varnish enterprise
  • varnish broadcaster
  • 2MTT

    • This week's episode of 2 Minute Tech Tuesdays is about the Varnish Broadcaster, a Varnish Enterprise tool that broadcasts messages to multiple servers.

     

     

    Varnish Broadcaster, as the name indicates, broadcasts messages to multiple recipients through a single endpoint. The response it returns isn’t a collection of individual responses from nodes but an aggregated result presented through a RESTful API. 

     

    Screen Shot 2021-07-12 at 12.42.19 PM

     

    This is the JSON responses that you might get:

    { method GET, “uri” “”, “ts” 1625656669, “nodes” { “Server1” 200, “Server2” 200, “Server3” 200 }, “rate” 100, “done” true }

     

    It contains information about the request, a timestamp, and the nodes that were used for broadcasting. In the example JSON response, servers one, two, and three were used, and all responded with a 200 status code, which means 100% success rate. We’ve been referring to servers now, but in reality, these will most likely be Varnish nodes, so let's talk about the use cases for Varnish.

     

    Use cases for Varnish Broadcaster

    The primary use case is cache invalidation. Thanks to the Broadcaster, purge requests can be distributed to multiple Varnish nodes at once, which makes life a lot easier. You can also send regular requests to warm up the cache or to synchronize objects between caches. Another Varnish feature, Varnish High Availability (VHA) does this and actually uses the Broadcaster for message transport.

     

    It's unlikely that you'll be performing HTTP calls to the Broadcaster yourself. You’re probably going to integrate this into your web framework, and if you already have a plugin for Varnish in your CMS or framework, it will most likely be compatible with the Broadcaster. 

     

    So how does the Broadcaster know which service to broadcast? Thanks to the nodes.conf configuration file, the broadcaster has the full server inventory. It is important however to keep it up to date. We can even choose to group various nodes, and thanks to the X-Broadcast-Group request header, we can choose to only send requests to servers that belong to a specific group. 

     

    And there are also some extra features:

    • Pick a random server from a group
    • Define the order of execution
    • Skip servers
    • Asynchronous requests
    • Management API

     

    Varnish_broadcaster_cta