Our New Asynchronous Architecture
In a real banking system, the ATM isn’t the only thing making debits on your account. You might use your debit card in a restaurant or supermarket, or you might walk into a bank and withdraw cash over the counter. You might have written a check that gets cashed a few days later. You’ll also get credits into your account, like when you deposit checks at the bank. The bank treats each of these events as a transaction, which it processes some time after the actual event has happened. Note that this kind of transaction is completely different from a database transaction, which we’ll talk about in the next chapter.
We’re going to change our architecture so that when the customer makes a withdrawal from the ATM, it posts a message about the debit transaction into a message queue. We’ll move the responsibility for processing this queue into a separate backend service. As the backend service works through the queue of transactions, it will store the updated account balance in a database so that the ATM (and our tests) can access it.
Figure 10, Enterprise messaging architecture shows how the new architecture looks. The ATM posts messages about transactions into the Transaction Queue. The Transaction Processor reads messages off that queue, reads the existing balance from the Balance Store, and then stores the updated balance back in the Balance Store. The ATM reads the account balance from the Balance Store.
Figure 10. Enterprise messaging architecture
Let’s look at the implications this new architecture will have on how we test the system.