Why build another HTTP router?

Both hardware and software routers like Citrix Netscaler, F5 Big IP, haproxy, varnish, nginx or apache require some form of configuration - the routing table - to route incoming traffic to services which can handle them. The routing table has to be kept in sync with the actual deployed set of services and instances during each deployment and each outage on every environment. This makes the routing table a crucial part of the configuration without the application cannot function.

Managing the routing table can be automated via API calls or tools like consul-template but that also requires configuration and/or tools. In the case of consul-template the config file template itself has to be kept in sync with the actual setup of the application. Finally, updating the routing table without loss of existing connections can be challenging.

fabio solves this problem by making the services themselves responsible for updating the routing table. Services already know which routes they serve since they have handlers who can handle requests for them. Once services push the routes they handle into the service registry (in this case consul) fabio can build the routing table and can re-configure itself on every change automatically without restart and without the loss of existing connections.

The motivation is also outlined in the presentation I've given at the dotGo EU pre-party in Paris on 9 Nov 2015. You can watch it here.

fabio was developed at the eBay Classifieds Group in Amsterdam and routes in total roughly 15.000 req/sec for the following sites without any measurable latency impact.

• marktplaats.nl
• admarkt.marktplaats.nl
• topannoncer.dbabusiness.dk
• cas.kijiji.ca
• www.kijiji.ij

(drop me a note if you want to have your site listed here)