If you provide a HealthPath in the config file, SRP will check the health of
your servers every few seconds and stop sending requests to any that fail until
the health checks start succeeding. Additionally, if any single request fails,
SRP will try that same request again using a different backend (3 tries max).
SRP includes a simple API to retrieve each services’ healthy backends. Combined
with something like github.com/egtann/lanhttp, the API enables your apps to
communicate over an internal network, rather than through the public internet,
without re-configuring your servers or modifying DNS.
By default the API is disabled. When configured with Subnet, the API responds
to /services over the appropriate subnet with JSON resembling the following:
lanhttp or similar can help you periodically call this API to update healthy
IPs and route *.internal traffic directly to the live IPs, skipping SRP
entirely, to keep chatty internal networks from impacting the performance of
Why build SRP?
Complexity doesn’t belong in the infrastructure layer. When something goes
wrong at this level, it can be catastrophic. You need to diagnose the issue
quickly and deliver a fix in minutes to meet your SLAs. A small, simple and
well-tested codebase is the only way to achieve that.
HAProxy, Nginx, and Apache are very complex, which is far beyond the need of
most projects. Several new Go-based reverse proxies that use autocert, such as
Traefik and Caddy, are very large and complex as well, with plenty of
opportunity for bugs.
Instead, SRP keeps it simple. There’s a much smaller surface for bugs. It’s
easier and faster to debug if issues occur (especially nice when they occur in
production and you need to roll out a fix quickly).