Nice. Good to see this has a shared storage option (Redis) for load balanced servers. The LE HTTP challenge gives no guarantee which A record it will use. Similarly, if your LB chooses another server even behind the same IP, it'd have to share the challenge state. I haven't read deeply, but I assume it handles the race conditions that can occur with auto renewal (i.e. different servers triggering auto renewal at the same time, overusing LE and hitting the quota faster). It was something I struggled with during the implementation of pluggable storage adapters for Caddy[0].
If you are going this scale, there is another way: Use your own DNS server and try the DNS-01 challenge. My setup works with [0]letsencrypt.sh, [1]pdns_api.sh, [2]PowerDNS4 (MySQL backend w/ replication) and a little script that distributes the certs and restarts services. The nice thing is, this works for anything you can put in DNS, you do not need not to respond to a HTTP request for a name (think mail server).
Yes, as long as you're using a shared storage adapter (like Redis), then for the most part, duplicate registration or renewal requests should be handled.
The approach to locking we're using is somewhat simplistic (and the specifics depend on the storage adapter you're using), so there might be some rare edge-cases in which 2 requests to Let's Encrypt slip through. However, that shouldn't actually affect the functionality (the last response simply wins). Here's a bit more detail in the code: https://github.com/GUI/lua-resty-auto-ssl/blob/v0.8.2/lib/re...
Re: hitting the quota faster, they have a staging environment that they explicitly mention as a target for client development. Probably not a helpful tip to you now, but others may find it useful.
0 - https://github.com/mholt/caddy/pull/913