It's nice to see this kind of thing covered. A company I worked for some years ago, LiveOps, also followed this methodology, because we had to. LiveOps was an

It's nice to see this kind of thing covered. A company I worked for some years ago, LiveOps, also followed this methodology, because we had to. LiveOps was and is a 'telephony in the cloud' provider, and the databases are in-line with some of the important call flows. Last I looked, in the ten years previous, LiveOps had handled at least one call from something like 15% of all of the possible phone numbers in the United States, and all of that data was available in a huge replicated mysql cluster spanning multiple datacenters. We had mysql tables with tens of billions of rows, replicated across many servers. And just to be crystal clear: there was absolutely no downtime allowed, ever, because downtime of any kind meant that phone calls would not go through. We used extensive feature flags, along with the techniques described in the stripe.com article, to achieve exceptional uptime, relatively ok operational overhead and pretty good development velocity. The point I'd like to drive home is that this is all possible even for medium sized organizations and moderately sized staffs. The important part is that everyone needs to keep these priorities, methods and techniques in mind, all the time, to make it work.