0. Intro 🎬

Taking a page from some illustrious, “illustrated” books—the classic computer networking tome titled TCP/IP Illustrated and the more-modern volume titled The Illustrated Network come to mind—we’re doing transaction processing in the spirit of the visually inclined mind this time.

Transaction Processing (“TP”  henceforth)—which can (loosely) be defined as the grouping together of operations (in computer programs) into a logical whole so as to simplify error-handling and concurrency concerns—remains every bit as vital today as it was when introduced a few decades ago. Yes, we technologists nowadays grapple with eventual consistency (more on ACID versus BASE soon) but TP stands its ground, retaining its vitality, and for good reason.

Read on to find out why.

(Remember, too, that this is positively not going to be a thesis on TP; far from it, in fact. Much digital ink has already been spilled in the service of exactly that sort of thing, and I have zero intention of rehashing that good stuff. What follows, then, is a hopefully enjoyable tour of the greatest hits in the land of TP.)

1. Yep, It’s… Shared Mutable State 📚

Oh yes, it all started here: The myriad ways in which we software practitioners grapple with the mind-bending complexity of reasoning through computer programs whose logic is permeated by shared mutable state. Imagine a freighter—yep, just like the one pictured above—whose laden goods are ripe for access by a hundred different concerned parties, without everyone colliding with everyone else, though. You get the picture, right?

Hence the centrality of dealing with transactions head first, not as an afterthought, and as nicely articulated in the following observation that

Some authors have claimed that general two-phase commit is too expensive to support, because of the performance or availability problems that it brings. We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.

– James Corbett et al., Spanner: Google’s Globally-Distributed Database (2012)

2. And Of Locking 📬

There is pessimistic offline concurrency. Then there is—and kudos here to fellow optimists for keeping the faith—optimistic online concurrency. Which one will you have? It really depends, of course, on your use case. But do be mindful of the notion of locking (computational resources) as you go about designing your beautiful computer programs.

In these days of plentiful multi-core processors (for our power-hungry computer programs) to lean on, locking becomes even more of a concern. Handle it deftly, and you’ll sleep (much more) soundly at night, knowing that your software is humming away and not locking itself into contortions of complication.

Onward.

3. Don’t Forget Recovery ⛏

Well, problems do happen: And it’s not even a matter of if, but of when. Given the inevitability of things going awry in the land of software, it’s best to be prepared for recovery. We have to strive hard to build resilience and recoverability right into our computer programs, to better imbue them with the quality of self-healing.

I know, I know: This is all easier said than done. But it can be done. So let’s roll up our sleeves and do it. (For inspiration, check the spunky look of grit on the faces of the stalwart workers pictured above.)

Yay!

4. Replication, An Ever-Present Concern 🐏

To keep a copy of the same data on several nodes so that it remains accessible if one node goes down—thereby becoming unreachable—your computer program can turn to another node (a replica) is just plain common sense.

Ah, therein lies the rub: Common sense, as the saying goes, is uncommonly uncommon. So it behooves us to do ourselves a favor and be prepared for replication. Our journey through the land of TP will be that much smoother.

Onward.

5.Let’s Queue It Up 🎡

Queues—and databases and caches—are here to stay. They have much in common, though we rarely think of them in the same breath. But I invite you to linger on what all is common to these programming constructs (i.e. queues, databases, and caches.)

While they clearly have different access patterns, they also happen to be first class citizens in the realm of TP. The ingested data may come in fast into our systems (this pattern becoming increasingly common), or it may come in slow (this pattern becoming increasingly uncommon), but you have to deal with data effectively all the same.

Hence, queuing. To paraphrase one more time the jingle of a popular credit card advertisement: Don’t leave home without it.)

6. “CAP,” Or Which Of The Two To Have? 🎁

Oh, that naughty theorem that is the CAP Theorem. Those initials, as you may remember, stand for Consistency-Availability-Partition-tolerance. I’m willing to wager that, of all the subtopics in the realm of TP, more digital ink has been spilled in the service of elaborating the ins and outs of CAP than on everything else combined.

So I’m going to point you to an excellent resource for all that good stuff.

Remember, though—and here I invite you to check the fabulously photogenic and exotic mushrooms pictured above, two to be precise—that when it comes to those three concerns (Consistency-Availability-Partition-tolerance), the thing to remember, one more time, is by way of this rhetorical question: Which of the two will you have?

7. ACID/BASE: Like Building A Bridge ⛵

And now I make good on my promise of giving you some pointers—again in the spirit of this being an illustrated take on TP—on the continuum that lies along the notions of ACID and BASE.

You see, when we do TP, we effectively group together operations into a logical whole (so as to simplify error-handling and concurrency concerns in our computer programs). And yes, we technologists nowadays grapple with eventual consistency, but TP retains its vitality, and for good reason: You can’t understand the one without understanding the other.

My advice: Using the two link atop this section—nicely complemented by the third one, which happens to be by yours truly—do spend some time becoming familiar with both.

8. All Aboard The TP Tram Now 🚂

So here we are, our journey fast drawing to a close. I hope you got value out of it. And I trust that you also appreciated why we keep coming back to the basics.

Having taken a page or two from some illustrious, illustrated books—the classic tome TCP/IP Illustrated and the more-modern title The Illustrated Network come to mind—as I had said at the outset, we did transaction processing in the spirit of giving you some memorable pictures with which to connect the concepts (of Transaction Processing, aka TP.)

(And you didn’t hear me use the phrase “pedagogical soundness”, did you?)

Good luck with your transactional adventures.