How Did Replicating Postgres Zone Data to Each Edge Cut an Australia Name Server Reload From Almost an Hour to Four Minutes?

On IndieRails, a name server in Australia could take almost an hour to reload because it connected to the core database and pulled all the zone data, while the same reload in Chicago took four minutes. Replicating zone data to each edge brought a full reload down to four minutes, and the edges now finish together.

Stock tools were tried early and did not work well across a large spread of systems or at the needed speed. The design still running today keeps the core application in Rails with a Postgres database behind it. A zone change sends a notification through a small Go application that lives at each edge, and the Go application fans that notification out to the name servers, which are written in Erlang. The name servers can reach back and ask for any changes missing from the payload. A portion of the Postgres database is replicated to the edges as well. Each edge holds a full copy of the zone data and reads it locally, so a full reload of an edge is expected to take four minutes.