I recently recorded a podcast with NGINX where we talked about the advantages of using real-time APIs over more traditional transaction-based APIs. I was struggling to find a way to relate how real-time APIs change the way we think about data and retrieval when it finally dawned on me that we already have a great example of a traditional transaction-based API and how we’ve moved away from it.
Does anyone remember checks? Surely if you’re of the age to be in networking or even starting out in the cloud you can remember those little slips of paper. The idea is simple enough. You carry around a book of negotiable instruments instead of cash. You promise to pay a specific amount of money (to the order of) to someone (pay to) on a date. You write the check details and give it to the person and they take it to the bank and get their money. Your bank makes good on the check and your account is debited for the amount you owe to the person.
Checks are straightforward and easy to understand. You don’t have to carry cash and you can make those checks work almost anywhere. But checks do have some quirks. The biggest one that most people are familiar with is the float, which is the time delay between when a check is written and when it is cashed. The float was one of the craziest things about check writing. You could write a check on a Friday afternoon and it might not be cashed for days. And if you write a check without sufficient funds in your account, you could potentially deposit those funds before the check was cashed. In essence, the transactional nature of checks allowed you to do some crazy things with how you wrote them.
This idea of writing “hot” checks for more than the amount in your account is one of the reasons why they aren’t really taken any longer by most smaller merchants. The amount of money and time it takes to rectify a fraudulent check for a business usually isn’t worth the amount that the check was written for. They became a liability rather than a financial instrument. However, most people still don’t like carrying large amounts of cash and may not have a credit card. So how did we finally start moving away from checks and their highly transactional nature?
The debit card gives us the ease-of-use that checks provide from not needing to carry large amounts of cash but marries it to a real-time transactional format. When you use a debit card at a POS terminal, the system queries your bank account balance on the spot. If you have enough money to cover the charge, it is removed from your account and sent to the merchant in near real-time. There’s no more float to worry about or use to game the system. If you have the money, the transaction is completed. If you don’t, the transaction is suspended until you can provide an alternate form of payment. The merchant doesn’t have to worry about finding out after the fact that there were insufficient funds. Which also means that there are no additional recovery or processing fees.
From Finance to Software
So, how does this analogy apply to the modern world of software APIs? Well, to start, most traditional APIs are more focused on transactional batch processing. Rather than sending every API call as soon as they are requested, there are several systems that collect those API calls and send them on as one big unit in order to optimize processing time. These calls are better used when the nature of the data response isn’t time-sensitive.
The analogy I use here is the way that small businesses process credit card transactions. They run the cards on a POS terminal for the amount of the sale or for a small extra amount to cover a tip. The transaction clears if the card has enough available credit limit but it isn’t confirmed until the end of the day when the card batch is sent to the processing company. The tip amounts are added to the final transaction total and processed as a group. This allows for credit cards to be taken and for transactions to be processed in batch to preserve bandwidth.
Most systems that use calls are starting to move to a real-time API model. Why? Because you can get the data back right away as opposed to having to wait for the batch to send or for the system to send back the response. Real-time APIs work best for smaller transactions to provide responsive interaction. Just like a user interacting with a webpage, the faster the response from the API, the more likely the customer is to adopt the use of real-time lookup. The batch processing model works because it returns a response immediately even if the transaction doesn’t post right away.
Real-time API calls mean you have the data that you need as soon as it is requested. No more waiting. No more hoping that things work correctly. But it also means that you need to make sure that your system is available at all times. You can’t create a real-time expectation and then find out your system is down or stalled trying to respond. That kind of sluggish response is going to have your developers rushing back to the “old” way of doing things. And you want things to keep moving forward to retire those old protocols and ways of thinking. Honestly, you want more companies to adopt real-time APIs. Because of the way that they can react to immediate data needs, you can get what you want or still use them the way that you have in the past with some creative programming on your side if the application can’t handle it for some reason.
Bringing It All Together
Debit cards have all of the advantages of checks and none of the drawbacks. Real-time APIs have all of the transactional advantages and so much more. The choice is pretty easy to make. And if you need any further proof of that, I want you to try using a check to pay in a big box department store sometime. The infrastructure put in place to speed debit card transactions has also been adapted to those that still prefer paper checks. The system takes the check but treats it as a debit card transaction on the back end. You can pay instantly with no float possible. The new way of doing things can adapt to the old ways until we can make the new way, the only way. It just takes a little time.
