I only ever heard good things about Varnish, Squid, nginx, Caddy and several others.

But IMO the main challenge is having the right caching key; this is why in-app caching is so powerful because you can cache an object through its ID and have any updating logic update the cached object, and any readers will be none the wiser because they’ll fetch it from cache 99% of the time (the other 1% being the object expiring due to TTL policy, or a race condition).

It’s trivially easy to setup many web servers to cache pretty much anything but then it falls on you to always return the right modified / etag response headers. Which is also pretty easy.

All in all, it is a “pick your poison” type of stuff really.

Plus:

• you can test it without running an extra service
• you can use libs to form BEAM clusters, sharing cache (or broadcast cache updates)
• one less single point of failure

But before you go the extra cache route: make sure you need it!

• most databases already have build-in (very powerful) caching. Their default settings are always on the safe side memory wise and mot always adjusted to the amount of cheap memory available in machines today. As a result they cache a lot less than your machine can handle. So before anything else: learn how to tweak the database settings.
• even simple caching layers add code and complexity.
• have seen many projects with fancy (but complex) caching layers only to have 100 requests…per hour.

Misread, sorry

You could be interested in these libs:

• https://github.com/krasenyp/plug_cache_control
• GitHub - tanguilp/plug_http_validator: Sets HTTP cache validators in Plug responses · GitHub