gistfile1.txt

# Traffic splitting proxy

## Background

Canary deployments are a popular way of testing microservices. In a canary deployment, a small percentage of traffic is routed to the new version of a service, while the original (presumably stable) version of your service manages most of the traffic. The service author can then monitor the new version of the service to make sure that it doesn't crash, etc. Then, traffic to the new version can be gradually increased.

A more sophisticated implementation of this approach can automate the monitoring/testing portion. With this approach, a proxy can multicast an incoming request to three separate instances:

* the candidate version
* the stable version (primary)
* the stable version (secondary)

Then, the proxy can then compare the responses to the same request in two different ways:

* Diff 1: the diff between candidate version and stable (primary)
* Diff 2: the diff between stable (primary) and stable (secondary)

If the frequency of diffs between Diff1 and Diff2 are approximately the same, then a reasonable observer can conclude that the new version is safe to roll into broader usage.

## Programming exercise

Implement, in C++11, an HTTP 1.x proxy that:

* multicasts incoming requests to 3 different destinations
* allows the 3 different destinations to be dynamically changed, without a proxy restart
* handles misbehaving destination servers, along with a test case for this situation
* outputs the responses in the console as such:

```
REQUEST <request_id> => (request info)
RESPONSE <request_id> primary => (response_info)
RESPONSE <request_id> secondary => (response_info)
RESPONSE <request_id> candidate => (response_info)
```

`(response_info)` is a placeholder for HTTP request/response information. Use whatever format is convenient.