Eventual vs strong consistency in distributed databases

Explanation of this topic starts with an analogy, taking an example from real life to understand the concept better.

I have the habit of writing something I called Tech notes on my laptop daily to summarize technical concepts that I have learned. It helps me to recollect them in an easier way whenever I want to.

But sometimes I used to worry about my laptop being stolen or what if it crashes. In response to the fear of losing Tech notes, I started backing them up on my external disk. To further reduce the possibility of losing them, I also purchased a Dropbox subscription.

Every fortnight, I update my external disk with revised and newly written Tech notes, and Dropbox gets updated as soon as I connect my laptop to the internet.

Here, I'm using external disk and Dropbox as sources of reading Tech notes while the laptop is being used for reading as well as writing them. (Master-Slave Model)

Now let's get to the point

Case 1: eventual consistency

whenever we use multiple replicas of a database to store data and let's say a write request comes to one of the replicas. In such a situation, databases had to discover a strategy to make this write request at one replica reach other replicas so that they all could also write the request data and become consistent.

Consistent here means that a read request for an entity made to any node of the database should return the same data.

Eventual consistency makes sure that data of each node gets consistent eventually. Time take by the nodes to get consistent may or may not be defined.

Data getting consistent eventually means it will take time for updates to reach other replicas. This implies that if someone reads from a replica which is not updated yet (since replicas are updated eventually) then it may return stale data.

My external hard disk also keeps stale data for a period of 15 days as it gets updated fortnightly. Let's assume John, my friend comes after few days of updating and asks for my hard disk.

John: I want your hard disk to read your Tech Notes.
I: Sure, why not. But it hasn’t been updated for the last few days.
John: I am fine with it.

Now hard disk was supplied to John immediately (low latency) at the risk of having stale data in it. But I'm sure about the fact that it'll get updated when the next fortnight starts.

Eventual consistency offers low latency at the risk of returning stale data. While on the other hand, we have something known as strong consistency.

Case 2: strong consistency

It says data will get passed on to all the replicas as soon as a write request comes to one of the replicas.

But during the time these replicas are being updated with new data, response to any subsequent read/write requests by any of the replicas will get delayed as all replicas are busy keeping each other consistent.

As soon as they become consistent, they start to take care of the requests that have come to their door.

This time my friend Verocell comes and asks for my tech notes.

Verocell: I want your last tech notes.
I: Sure, why not. I will share a Dropbox link with you. 
    But Verocell, access it after few minutes 
    as I have written a new note on the laptop 
    which will get synced with my Dropbox in 2-3 minutes.

Now Verocell was able to access up-to-date tech notes but after few minutes delayed.

Conclusion

Strong consistency offers up-to-date data but at the cost of high latency.
While Eventual consistency offers low latency but may reply to read requests with state data since all nodes may not have the updated data.