For both block and object storage we use Ceph ( https://github.com/ceph/ceph ) as our backend storage engine. The requirement of distributing copies of user data effectively while keeping them fully consistent was paramount to us. That and the fact that we like to use open-source tools throughout our stack (and contribute upstream whenever possible) led us to make this choice. Regarding the design of Ceph, I like to point people to https://www.youtube.com/watch?v=7I9uxoEhUdY since it gives an overview of the internals very nicely. :)

Delivering both block and object storage platforms out to our users involved our very talented designers, engineers, infrastructure, operations, product, support and marketing teams, so there's no one particular "field" that you need to be best at. ;) I can speak specific to storage engineering a little bit. I don't think there's a strong requirement of a university degree as such, but having the knowledge (and/or experience) of dealing with persistence (along with the problems that come with it) and various access patterns for large amounts of data would certainly be useful. We have built several services internally that manage information flow and persist metadata of storage clusters, that don't deal directly with the underlying user data but are critical to the control plane and having generic software engineering skills is quite useful here.

Hi Adam, Thanks for mentioning your use-case! Designing and scaling applications can be challenging and sometimes tricky to get all the aspects right. It's also important to see what kind of use-case we are dealing as one solution might not map equally well to all problems. I think one way to scale a typical system that has a "stateless" frontend sitting on top talking to a persistent data store, is to decouple those two pieces. The backend datastore can be mounted on a separate droplet that has block storage attached to it (and hence it gets all the high-consistency+fault-tolerance guarantees for all the valuable data it is dealing with) and there could be multiple wordpress instances that connect to it. That way you can scale wordpress instances to handle skews in traffic, and your data store volume is always protected even if your database droplet undergoes any problem (since the actual storage is remote to it and available from any new droplet you create from a snapshot for instance). However, a lot would depend on your use-case and if wordpress (or any other blogging tool) allows such a setup or not before you decide to head down this route. :)