Eventual Consistency With One Database

Does eventual consistency only cover data replication (copies of the same data):

To give an example without copies of the same data:

• I have one single database.
• I have Microservice A that performs an action. Let's say I deposit funds into my bank account. The microservice in this example ONLY handles storing your deposits and withdrawals, but nothing else to do with your account.
• When Microservice A is finished, it communicates to Microservice B that it needs to do update the balances on the account.
• Microservice B updates the account balances

In this example, there is a time between the deposit being made and the account updating the balances where the balance will be "incorrect".

Is this an example of Eventual Consistency -- despite having one database, my data will not be tell the full story right away...but it will eventually... :)

You can easily have eventual consistency with a single database. Let's dispense with examples involving transactions of money, since this seems to elicit many feelings and opinions.

Instead, consider a database that keeps track of an online game. Whenever you win a match, the database immediately stores the result of the match. It also publishes an event with information about the result on an asynchronous pub/sub bus.

One subscriber picks up the information and may use it to update a leaderboard.

This is a common performance optimisation, since you don't want to slow down the update of game state by also writing to a leaderboard table. And you probably also don't want to base the leaderboard on a direct query of all match results ever, as this is likely to require a full table scan (unless the results table is sorted by score, perhaps).

While the asynchronous message is en route, you may have an inconsistency in the system where the leaderboard doesn't reflect the latest result.

In fact, if you imagine that there's sufficient contention, by the time the leaderboard gets updated, a new high score may be on its way over the message bus. Imagine that this keeps happening. Such a system may never actually get to a consistent state, but we still call it eventually consistent because, if you imagine that you stop all external activity and let the system drain all asynchronous queues, it will eventually settle into a consistent state.

The above example is based on asynchrony and some denormalization, but under such circumstances, you can easily design eventually consistent systems even on a single database.