Designing for eventual consistency
Depending on the type of applications you have designed in the past, you may or may not have come across the concept of eventual consistency (unless you have worked extensively on distributed transactions oriented applications). However, it is fairly common in the cloud world. After a data update, if your application can tolerate a few seconds delay before the update is reflected across all replicas of the data then eventual consistency can lead to better scalability and performance.
Cloud platforms typically store multiple replicas of the data to ensure data durability. For example, the replica of a database table could be stored in several geographically distributed locations.
Normally, eventual consistency is the default behavior in a cloud data service. In case the application requires consistent reads at all times then some cloud data services provide the flexibility to specify strongly consistent reads. However, there are several cloud data services that support the eventually consistent option only.
Another approach used to improve scalability and performance beyond the capacity, that is CPU or I/O or both, of a single instance of your database, is to deploy one or more read replicas close to your end users. This is typically used for read-heavy applications. The read traffic can be routed to these replicas for reduced latencies. These replicas can also support resource heavy queries for online report generation or serve read-only requests, while your main database is down for maintenance or operations activities.
Note that changes to the source database are applied to the read replicas continuously, but there is a small lag involved. Hence, read replicas are considered to be eventually consistent.