Stop Talking About The CAP Theorem - by Robby@NextPath
SubscribeSign in
Stop Talking About The CAP Theorem<br>On Avoiding "Buzzword Driven Development"
Robby@NextPath<br>Jul 07, 2026
Share
Focusing on more useful interview topics, I’ve been genuinely concerned about this trend in System Design interviews. SD are my bread and butter, and they’re a large part of the draw for candidates to working with NextPath. I’ve nearly worn out my soapbox on this topic, so rather than beating this dead horse, I figured I’d write up my thoughts to share.<br>In addition to my rant, I highly recommend you read the Wikipedia article on CAP Theorem, Vivek Bansal’s excellent primer on the subject, and Martin Kleppmann’s post about the technical deficiencies of the theorem as it relates to databases.<br>Also - if you have questions, drop them in the AMA box, or even better, come to the NextPath “Ask A Hiring Manager” event July 16th! It’s free, and will be a great opportunity to ask anything you’ve ever wondered about the industry, the hiring process, and how to get good at engineering.
Okay, lock in. You’re interviewing a candidate for a Senior Fullstack role. It’s the third round for this candidate, and they’re the seventh to get this far. Their resume is promising, but it’s the System Design interview - this is the one that has tripped up most of the prior candidates.<br>The candidate has started off pretty solidly. They asked good questions to define the scope, didn’t introduce unnecessary complications when discussing requirements, and while they didn’t blow you away with their instincts on acceptable latency, they were directionally... passable.<br>Ok, now here’s the moment. Brace for it. Maybe it won’t happen?<br>No such luck.<br>“Now let’s discuss the the CAP theorem and whether we should prioritize consistency or availability.”
A week later I was meeting up with a hiring manager at a local AI startup. We were discussing trends in interviewing, and I finally realized I wasn’t alone.<br>Them: I’ve had candidate over candidate who do so well in interviews but then we get to System Design and it just... gets weird<br>Me: How so?<br>Them: They just seem like robots. They ask the same questions, use the same approaches, and just aren’t thinking about the problem at all.<br>Me: What kind of questions are they asking, by chance?<br>Them: Well.. this is weird but, they keep asking-<br>Me: About the CAP theorem?<br>Them: YES WTF
If you’re new here, I want to give you some context on myself. I’ve been building teams at tech companies for well over a decade now. I’d heard of the CAP theorem in college, but it never really came up afterwards. Suddenly, starting in the past year, it’s been brought up in roughly eight out of ten system design interviews I’ve conducted (I did the math). I won’t go into why this is suddenly happening - despite never coming up in any interviews I have taken, as candidate or part of the hiring team, or in any job I’ve ever worked in. Let’s just say there’s a certain interview prep website that has gotten fairly popular during that timeframe.
I wish I could say “Goodbye” to this site, wink wink.
NextPath Mag is written by a SWE Leader who has built and scaled teams at companies of all sizes, and now spends their time coaching engineers such as yourself. If you like this content, please support by subscribing
Subscribe
But isn’t the CAP theorem useful?
Absolutely. Let’s first cover what the CAP theorem is:<br>The CAP theorem states that distributed data systems can simultaneously guarantee at most two of three properties:<br>Consistency (all nodes see the same data at the same time)<br>Availability (every request receives a response)<br>Partition Tolerance (the system continues to operate despite network failures)<br>In a distributed system, you have Network Partitions . These are parts of your system (databases, typically) that cannot communicate with each other. Because of that condition, it is impossible to have both High Consistency (HC) AND High Availability (HA) as priorities in your system.<br>Put plainly, if two servers cannot talk to each other, they either have to wait until they have the most up-to-date information to respond to requests (HC) or send along whatever info they have regardless of accuracy (HA). So therefore, the decision is whether or not to favor HC or HA.
If you pick wrong, you get a goat (this is an old reference, children).<br>I Think I Get It… Wait No, I Don’t.
Here’s a real life example from my time at Wayfair. I was leading development of their personalization service, an API that served hundreds of millions of recommendations per day. The API I was building needed to serve relevant recommendations based on pre-crunched data from hundreds of machine learning models, which were retrained daily.<br>If the data was stale, that wouldn’t be the end of the world - yesterday’s recommendations were good enough. And if the service timed out or went down, the frontend just hid the recommendations section or provided hardcoded products...