First, let me say up front that I value your verve and appreciate your desire to experiment and learn and push frontiers. Bravo on all that. The problem with

First, let me say up front that I value your verve and appreciate your desire to experiment and learn and push frontiers. Bravo on all that. The problem with tight coupling -- especially across concerns and software layers, as with 'etcd -> load balancer' -- is that it's an immediate withdrawal from the great Bank of Technical Debt. Some time in the future, one of the following things will happen: 1. Etcd will want to perform one unit of positive technical change, and either that behavior will break your code, or you will be forced to fork versions, or etcd will be forced not to make that change by the popularity of your code. 2. You will want to perform one unit of positive technical change, but etcd will, for whatever political, architectural, or technical reason not wish to support this change. You will either abandon your idea for lack of upstream technical support or be forced to fork etcd. The neglect of these incredibly common occurrences is itself now incredibly common. It underpins, e.g., systemd development, which in turn appears to be informing coreos and docker development, and since those are the new-shiny-toys, a lot of people seem to think that's just the way we should all think now, that the 'unix philosophy' is ripe for disruption(tm). Problem is, invariably, coupling turns out to be the most important artifact in all of computer science. It's worse than naming things, it's worse than cache invalidation, it's worse than off-by-one errors. And the worst kind of coupling is the kind of coupling that crosses stack boundaries for no obviously good reason, because the amount and kind of reasoning that has to happen at an operational level when that stops working in production is both severe and very difficult to resolve. So again: applaud the desire to learn, and experiment. The coupling: please, please don't. The marketing of a test solution as something to consider using: you don't need that to build your portfolio, just put the project up and say it's a test thing. And preventing cascading failures with weighted round robin, etc: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-balance%20url_param http://cbonte.github.io/haproxy-dconv/configuration-1.5.html...