This blog post is part of a series on non functional requirements, and how they take most of the effort.
The scenario
You want a third party to implement an application package to allow people to buy and sell widgets from their phone. Once the package has been developed, they will hand it over to you to sell, support, maintain and upgrade and you will be responsible for it,
At the back-end is a web server.
Requirements you have been given.
- We expect this application package to be used by all the major banks in the world.
- For the UK we expect the number of people who have an account to be about 10 million people
- We expect about 1 million trades a day.
See start here for additional topics.
What is consistency?
After an end user sells some widgets, if you display the status you should see the number of widgets owned has gone down, and the money in the users’ account has increased. The number of system wide available widgets has gone up, and the amount of money in central account has gone down. All the numbers should be consistent. If there is a problem with the system, such as a database outage, or a power cut, when the system recovers the data should still be consistent.
Wikipedia says
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps.[1] In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.
If there is one big database this is pretty “obvious”.
There are databases with “eventual consistency“. These databases are distributed, and highly available, and it takes a short time (seconds) for updates to be propagated to other instances. Eventually all instances become consistent.
You may make an update on your phone, but when you look with your laptop’s browser, it takes a few seconds to reflect the update – because a different server and database instance were used.
Distributed databases
A single database is a single point of failure. You can have databases which are distributed. For example you have many sites and a database instance at each site. When every a user makes a trade, the local database is updated, and at commit time, the updates are sent to the remote sites, and the changes applied to the other database. Immediately after the trade, the databases are inconsistent. A short time later (seconds) all databases are consistent.
This looks a pretty simple design. However It gets more complex when there are updates occurring on all instances at the same time.
For this to work, the update sent to the other system will reflect the changes such as “10 widgets sold” “credit account with $100”. Rather than absolute values “current balance $400”
What to think about?
You need to consider your availability targets. 100% is achievable, but you need to consider you will need to shutdown machines an reboot to apply fixes, or to move the machine instance.
Can you tolerate a eventual consistent environment, or do you need totally consistent image?
How will it scale?
Will you partition your data so groups of users such as with names in the range A-C go to one server, D-F go to another server etc?
Consider having name and address information in one database – as the information does not frequently change, and dynamic information such as number of widgets, and account balance in another database.
If you have an eventually consistent database, how do you stop people from having multiple sessions all simultaneously trying to transfer your money to an external bank account – and exploiting the delay when using eventual consistency .
ColinPaice 