Eventually Consistent #1 - Learning vs Understanding

We don't have a learning problem, we have a understanding problem!

Hi, I’m Sahil. I usually write about distributed systems, system internals, and backend architecture. This is a new kind of post. If you are here for the technical posts, wait till next week, thank you.

I call it Eventually Consistent, not just because it’s a clever systems metaphor (which it is), but because it captures how I experience growth: inconsistent, messy, and human, but eventually converging toward something stable.

These aren’t tutorials. I am no expert. They’re bits and pieces from the middle of the process, inconsistencies included.

---

What’s this about?

I’ve written a lot about distributed systems, infra, and debugging problems. But before any of that, I had to understand the concept of “learning”. And I don’t mean "study more." I mean actually understanding, in a way that shows up when we're tired, under pressure.

This is not a tech-breakdown post.
But it’s probably the most important thing I’ve written down, for me or maybe anyone else.

The Problem

We often think the problem is learning.
But it’s not.

We’ve gotten really good at consuming docs, blog posts, YouTube, conference talks, and giving prompts to ChatGPT at 1 AM. But when it comes time to apply that knowledge, to explain it, teach it, build with it, most of us freeze.

Not because we’re dumb.
But because we never built a model. We just skimmed through them and hoped it would stick.

In this post, I want to break down why most of us struggle with understanding, not learning.
And how we can flip our mental model: from input-first to problem-first.
From memorization to intuition.

This is as much about systems as it is about self.

---

The Curriculum: Pattern Matching and Memorized Intuition

Let’s look at how we are “taught” to think and learn.

1. Introduction to topics (T1, T2 … Tn)

2. Teaching in-depth about them

3. Learning their patterns

4. Given a set of problems, we remember the patterns and try solving them

5. Eventually, we start mapping questions → topics → patterns

It’s neat. It’s organized, it’s fast. And it works for a while, or it might work forever in many cases.

Now, when we are given a question Q1, we start processing all the topics we have gathered over the years to map them to Q1, which might solve the problem.

Patterns match until they don’t

The “Broken” Way of Learning

We see this while learning DSA.

We know a set of topics: 2 pointers, array, linked list, dp, stack, queue, graph, etc.

We start solving problems for those specific topics, and then we try matching a new problem to the topics we know.

It’s like searching for a needle in a haystack of patterns.

And system design interviews aren't that different either.

• “Fast access?” → cache.

• “High write load?” → NoSQL.

• “Geo-distribution?” → CDN.

• “Async?” → Kafka.

This helps us “crack” interviews.

That’s not system design, that’s pattern matching.

We failed to ask the real questions —

• What was the original problem that needed caching?

• What constraint made a CDN necessary?

• What tradeoff led to eventual consistency?

If we don’t understand the pain behind the solution, we’re throwing keywords in the hope that something works.
What happens when we are faced with a problem that doesn’t fit any known pattern?

We break.
Because we never learned the “WHY”, just the “WHEN”.

Flip the Map: Problem → Exploration → Intuition

Let’s look at a different way to approach learning.

1. Start with the problem. What’s actually happening? What’s failing? What’s unknown?

2. Brute-force our way into it. Try solutions, even if they feel wrong. Start somewhere.

3. Trace back what helped. What problems did we solve to get to the solution?

4. Learn those, now tied to experience. That’s what sticks.

We haven’t mapped the problem to anything; it’s a separate entity on its own, having a different solution, a separate intuition.

Why is it better?

Because this is exactly how that original solution was discovered in the first place, and this is what we call “intuition.”

Implementation vs. Intuition

Let’s say we are asked to use gRPC in the next service.

We could go about it like —

• Watch a YouTube video

• Ask ChatGPT for a sample project, maybe tinker with it a little bit

That would work, we will be able to build it surely, but let’s take the approach discussed above.

• Why gRPC? What problem does it solve?

• Why HTTP/1 didn’t work? Where does it break?

Then, once we’re done implementing:

We go back and ask: “What did I learn about the system by trying this?”

That’s how we turn tools into understanding, not just buzzwords.

So the next time we are asked about gRPCs in our interview, we will not only be able to say WHEN to use it, but also the WHY behind it, and in my opinion, the WHY matters far more.

Doing What I Preach

The irony and beauty are that this very post (and my other posts) are applying what it preaches.

We did not start with memorized frameworks.
We began with a problem: Why do we know so much and understand so little?

Then, we explored what was broken in the current model, proposed solutions, and asked why it might work better.

That process, looking at the actual pain, exploring possible solutions, tracing them back to root causes, is the learning model.

We’re not being handed a list of study tips.
We are watching the solution unfold and building our own understanding in parallel.

I am no extraordinary, I used to skim through docs on indexing, CAP theorem, trying to wrap my head around these topics.

I knew indexing made reads faster, and writes slower, but I didn’t ask WHY?

I went into B+ Trees, how they are designed, what happens when we read a key vs when we write a key, how the tree re-balances, to truly understand WHY it slowed writes.

I knew CAP theorem existed, I knew its definition and what those 3 concepts are, but I never asked WHY it existed?

I implemented a basic distributed key value store, with eventual vs strict consistency model, understood why we can’t be consistent and available at the same time when network partition existed, because it was a problem I faced while building my store.

If it clicks, it sticks.
And if it sticks, we can reuse it, in tech, in systems, in ourselves.

Extending it to our lives

I came to the following conclusion after thinking about it for a long time. It might sound cheesy, but bear with me for a moment.

This whole “problem → exploration → intuition” model applies just the same to our emotional and personal lives.

Just like in code, we try to pattern-match feelings:

• "Oh, this is burnout."

• "Maybe I’m just tired."

• “Maybe I just need to give it time” (which might be true in some cases)

What if the pattern doesn’t fit? We panic, we don’t know what’s making us behave that way, or why we make decisions like that.

Let’s try figuring out using the above approach —

• What is the problem?
  Trace it. Observe. Read our mental logs.
  Look at when things started breaking. It might take days, weeks, or months to get there, but we will eventually.

• What are the possible causes?
  We might not have clear solutions, but knowing the problem, knowing its origin, will reinforce the fact that we can act on it, prevent it in the future, or maybe work on it slowly.

Even then, life is not that simple; we might not get to the bottom of our problems, we might never even understand the problem, but at least we would know ourselves better.

Like in engineering, the first answer usually isn't the right one.
But asking the right questions gets us there, eventually.

Eventually consistent, that’s what we are.

Final Thoughts

Let’s be honest about it.

If we can’t explain what we’re doing, we don’t understand it.

If we can’t trace why a tool is being used, we’re just copying.

If we’re waiting for someone to teach us, we’re already behind.

We’ve tricked ourselves into thinking that just skimming a blog or docs equals progress.

It doesn’t.
Understanding is the only metric that matters.
And understanding only comes from friction.

So, next time we are lost in a system or life, we don’t bookmark another guide, don’t start another self-help guide, and don’t ask ChatGPT to create another demo project.

We go inside our brain.
We break something.
We build something on our own.
And then ask, what did I just learn?

If it didn’t hurt a little, it probably didn’t stick.

---

Next week

I will be posting the 2nd edition of Breaking Prod, and there we will look into “How Discord built their search system”.

Understanding the internals of ElasticSearch and how to build an efficient system by building on top of existing systems to reduce cost.

See you next week. Stay tuned.