Service Level Agreement

The following document outlines the minimum guarantees offered to subscribers of the Zip Code Services™ API service (herein: Service) and the remedies offered if those guarantees are not met.

In practice, we have a much higher actual value than what is guaranteed in this document. Specifically, our uptime has been 100% with a corresponding average response time of 30 milliseconds (excluding Internet latency) because we offer a redundant solution.

Zip Code Services™ guarantees at least 99.98% availability for the Service and takes appropriate precautions to ensure that any one user on the system does not adversely affect any other user in causing response times to rise above a 500 millisecond threshold (excluding Internet latency). In the event that these levels are not maintained as provided herein, service credits will be issued to the accounts of the affected users. 

Zip Code Services™ guarantees the Service will be available no less than 99.98% during a given calendar month. For the purposes of this document, a "web service outage" is defined as a period of time during which no traffic can ingress or egress from all instances of the intended Service for five consecutive minutes. 

Zip Code Services™ strives to ensure that all requests are processed in a timely fashion and, to this end, utilizes various techniques to offload and balance traffic to all available physical servers. For the purposes of this agreement, "response time failure" occurs if, during five consecutive minutes, the Service takes longer than 500 milliseconds to respond to a single address lookup (excluding any Internet latency). 

Internet latency is defined as the amount of time it takes for a given request to receive a response when traveling over a public network, whereas internal or application latency is defined as how long it takes the Service to interpret a request and return a response. Internet latency is something over which Zip Code Services™ has absolutely no control (such as a 3G iPhone cellular connection from England) and is expressly excluded in this agreement.

Application latency can be roughly calculated by establishing a persistent HTTP connection, issuing a single request over that connection, and then subtracting the ping time to that particular machine instance of the Service. Keep in mind that setting up a secure HTTP connection is a costly operation that requires multiple round trips between the calling code and the machine on which the Service is running. (See below.)

Internet latency is visible when a new HTTP connection is established between calling code and the application servers. Specifically, HTTP exists on top of TCP and requires a minimum three-way handshake to establish a connection between two parties. Pure HTTP then sends a stream of packets and receives a stream of response packets with ordering and retransmission of lost packets occurring from time to time due to network congestion and factors that affect packet loss and are beyond our control. (Again, think cellular connection in the middle of England.) HTTP on TLS (HTTPS) compounds the Internet latency visibility because of an additional set of handshakes that occur when asserting the identity of the server and establishing a "shared secret" between the two parties.

For best results, maintain a pool of pre-established "keep-alive" HTTP connections and then balance requests across connections within that pool. Although this step is not required and may not be advantageous for a given use case, it will dramatically improve response times by avoiding the connection handshake. In addition, if the calling code supports "HTTP pipelining" or the ability to issue multiple requests over a single connection simultaneously, performance can be further improved. 

Inherent in the TCP protocol design is a probability of failure. The canonical example of this is where one or more images fail to load when viewing any given website in a browser, and where a simple page refresh "fixes" the problem.

Because requests to and responses from the Service are transported over unreliable networks, any single request or response failure cannot accurately predict and/or conclusively demonstrate a network outage or response time failure. Similarly, the HTTP and TCP protocols provide no quality of service guarantees over a public network such as the Internet or cellular networks. Therefore, it is only in the aggregate that a failure in availability or response time can be truly detected. 

From time to time, a given data center may become completely unavailable for any number of reasons such as construction crews severing physical cables, storms knocking out electrical power, Internet backbone provider outages, various kinds of network operator equipment congestion and/or failures, or any other number of factors beyond the control of Zip Code Services™. It is primarily for these reasons that we utilize multiple, fully independent data centers from no less than two data center operators running at any given time.

Any code calling into one or more instances of the Service must be able to handle complete loss of a given data center by removing any failed IPs from the request rotation. Any such data center or network operator outage is expressly excluded from the availability and latency guarantees offered within this agreement so long as at least one data center remains operational and able to process requests according to the tolerances set forth herein.

For absolute best performance, the calling code should maintain a pool of pre-established connections open to multiple data centers and then balance requests across the pool. 

The uptime and response guarantees set forth above do not apply to any unavailability, suspension, or termination of Service, or any other Service performance issues:

If Zip Code Services™ fails to meet the uptime and response guarantees set forth herein, Zip Code Services™ will apply service credits to the affected accounts according to the following schedule: