Looking at our service, now that it's using RethinkDB, we can have the best of both worlds and enable sharding and replication at the same time. Head to the Administration Console and click on the Tables tab at the top:

Click on our images table and scroll down:

You can see that our table is on one shard (the default), with only one replica per shard. Down the bottom, you can see the server (blue link) on our cluster that is holding the table. Click on Apply configuration:

You can configure the number of shards and the number of replicas of every shard. The limitation on four shards and four replicas is because our cluster has only four nodes. Any number above that would not make sense.

Let's configure our table with two shards and two replicas per shard and apply the configuration. Wait a couple of seconds and look at how our table is distributed:

If one node restarts, the database keeps running without a problem. It will recover and synchronize everything when the node comes online again. Let's just try that. Head to a console of one of the Docker machines and restart one of the database containers.

If you keep the administration console open, you should see something like the following screenshot for just a few seconds:

The server then reconnects, and everything recovers immediately. But this is a specific feature that will vary according to the database server and cluster type. Your operations' team should be comfortable with the database server chosen to run in production.

We now have a production-ready environment that we can tweak and scale to our needs.