Read-heavy APIs, which I like to setup as: A central location to take writes. Writes to this location go into a database and a durable, at-least-once, queue (w

Read-heavy APIs, which I like to setup as: A central location to take writes. Writes to this location go into a database and a durable, at-least-once, queue (writing to the queue is as important as writing to the database). Then you put your API servers in different geographies (and preferably different hosting vendors). They listen to the queue and update their own storage (which could itself be a full relational database). Edges aren't caching layer, since all the data is expected to be there (so, no miss). But certainly some of the data could be loaded in this way. The edges can also take some writes and send it back to "central", but you have to not care too much about the consistency (and maybe even accuracy) of that specific data. Throw a latency-aware DNS on top of it (anycast, geo) with a short TTL and good health checks and you don't care too too much about uptime, allowing you to focus on raw price and performance. Ironically, the only time I remember a serious outage (at a single location) was during a DDoS against a specific location at a much more expensive provider (not-rackspace-but-the-other-one-you're-thinking-about) which, of course, null routed us.