As an example, consider a typical banking operation, moving $500 from your savings account to your checking account. This seems like a single operation to the user, but in fact consists of two: debiting the savings account by $500, and crediting the checking account by $500. Imagine what would happen if the debit operation succeeded and the credit did not, $500 would disappear.
Transaction processing systems allow these two operations to be "grouped" into a single transaction, so these sorts of problems cannot occur. They do this by making copies of the data in question, and then running the operations on the copied data. When both commands have successfully completed, the changed data is written back to the system in a single operation. If either operation failed, the copied data is simply discarded, and an error is reported. This desirable property is called atomicity, and is one of the desirable ACID transaction properties.
For many years transaction processing was the domain of the database management system, making sure that any changes to the database were complete. This worked well for most applications, many users could all run on top of a single client-server database.
In more recent years this model has become considerably more difficult to maintain. As the number of transactions grew in response to various online services, a single database was no longer a practical solution. In addition most online systems consist of a whole suite of programs operating together, as opposed to a strict client-server model where the single server could handle the transaction processing. Today a number of transaction processing systems are available that work at the inter-program level.
See also: Database transaction