90 Days of Learning Distributed Systems with AI: What Worked and What Didn't

Why I Started This Experiment

In early 2026, I decided it was time to seriously level up my distributed systems knowledge.

As a backend engineer with five years of experience, my daily work consisted of writing business logic, calling APIs, and fixing bugs. I knew the surface-level stuff — what a cache is, how load balancers work, what NoSQL means. But ask me to design a chat system that scales to 10 million users, and I'd freeze.

The traditional path would be: buy a few heavy textbooks (Designing Data-Intensive Applications, System Design Interview), spend six months reading, and hope it sticks. But as someone with a full-time job and limited energy, I knew that wasn't going to happen.

Then an idea hit me: What if I used AI as my personal tutor?

Not to write code for me. Not to generate cookie-cutter answers. But to actually teach me — with feedback, quizzes, and simulated interviews.

This article is the raw, unfiltered account of that 90-day experiment.

Phase 1: The Wrong Way to Start (Days 1-3)

First Mistake: Asking AI to "Make Me a Study Plan"

I opened ChatGPT and typed: "Create a 90-day study plan for distributed systems."

It spit out a beautiful table in 5 seconds:

Looked perfect. Until I actually tried to follow it.

The problem? This plan was designed for an imaginary "ideal student," not for me.

ChatGPT didn't know my actual knowledge level. It assumed I knew all prerequisite concepts. It didn't account for my energy fluctuations after a full day of work. And most importantly — it didn't know how I learn best.

The Pivot: Diagnostic First

On day 3, I changed my approach entirely. Instead of asking for a plan, I told ChatGPT:

"I'm a backend Java developer who uses Redis and MySQL at work but not deeply. Test my distributed systems fundamentals using multiple-choice questions. 10 questions per session, adjust difficulty based on my accuracy."

We did this for three days. The results were humbling:

• CAP theorem & basic concepts: 60% accuracy
• Database fundamentals (sharding, indexing, replication): 70%
• Distributed systems theory (consensus, consistency): 30%
• System design case studies: 20%

Armed with this data, I asked AI to generate a targeted study plan.

This time, the output was completely different:

Days 1-20: Distributed Theory Intensive
- Days 1-5: CAP theorem & BASE (with concrete examples from real databases)
- Days 6-10: Consistency models (strong vs. eventual, why most systems choose eventual)
- Days 11-15: Consensus algorithms (Paxos/Raft core mechanics)
- Days 16-20: Partition tolerance & split-brain scenarios

Days 21-40: Deep Dive into Databases
- MySQL replication topologies, sharding strategies, NoSQL tradeoffs
- Practice: design a data storage scheme every 3 days

Days 41-70: Hands-on Design
- Deconstruct 2 real-world system designs per week
- Draw architecture diagrams, then let AI critique them

Days 71-90: Sprint Mode
- One mock system design interview per day
- AI plays interviewer, I present my solution

This plan actually knew what I needed. Key lesson: don't ask AI for a plan until you've let it assess your real skill level.

Phase 2: Finding the Right Learning Method (Days 4-30)

I tried three learning modes. The difference in effectiveness was shocking.

Mode A: AI as Lecturer (Days 4-10)

Usage: "Explain the Raft consensus protocol with a concrete example."

Effectiveness: ⭐⭐⭐

ChatGPT's explanations were clear and structured. It used great analogies. But there was a fatal flaw: I forgot everything within 48 hours.

I was in passive consumption mode — like watching YouTube tutorials. It felt productive in the moment, but nothing stuck.

Mode B: AI as Quizmaster (Days 11-18)

Usage: Read material first, then ask AI to generate 10 practice questions.

Effectiveness: ⭐⭐⭐⭐

This was significantly better. After learning about consistent hashing, AI gave me this:

"A distributed cache has 5 nodes. You add 2 nodes. Using consistent hashing, how much data needs to be moved on average? Without consistent hashing?"

This forced me to actually understand what "minimal data migration" means in practice.

Mode C: Feynman Technique x AI (Days 19-30)

Usage: After learning a concept, explain it to AI in my own words. AI acts as a student, pointing out gaps and errors.

Effectiveness: ⭐⭐⭐⭐⭐

This was the game-changer. After studying distributed transactions, I spent 20 minutes explaining Two-Phase Commit (2PC) vs Three-Phase Commit (3PC) to AI. Its feedback:

"Your explanation of 2PC phases is largely correct, but you missed a critical point: you didn't mention the coordinator single-point-of-failure problem. In practice, if the coordinator crashes, all participants hold resource locks indefinitely, potentially bringing the system to a complete halt. This is exactly why most modern systems prefer the Saga pattern over 2PC."

That feedback stuck with me in a way no textbook ever could. The fact that I had to actively construct an explanation and then get corrected created a much stronger memory trace.

From Day 19 onward, my fixed workflow:
1. Read source material (book, article, or AI-generated overview)
2. Explain it to AI in my own words
3. AI corrects gaps and adds context
4. I update my mental model based on feedback
5. AI generates quiz questions to verify retention

The core principle: AI doesn't handle "input" — that's my job. AI only handles "validation."

Phase 3: Simulated Whiteboard Design (Days 31-60)

The Most Valuable Practice

System design interviews revolve around one thing: whiteboard design. Given a vague requirement, you need to draw an architecture and explain your decisions.

This is the hardest part to practice because you need a live audience that can give feedback. I tried finding mock interview partners — but everyone's busy. Once a week was the best I could do.

AI solved this problem effortlessly.

My practice flow:

1. Ask AI: "Give me a system design question as an interviewer would"
2. AI generates a prompt (e.g., "Design a URL shortening service")
3. I spend 15 minutes drawing an architecture on paper
4. I "present" my design to AI as if in an interview
5. AI scores me and gives improvement suggestions

First attempt: URL Shortener

My design:
- MySQL for URL mappings
- Base62 encoding for short codes
- Redis cache layer

AI scored it 7/10 and identified three blind spots I hadn't considered:

1. "Your short code is auto-increment based. Anyone can enumerate all your short URLs by incrementing the ID. Consider hash-based generation with collision detection."
2. "No expiration strategy for short codes. Your database will grow unbounded as mappings accumulate."
3. "Your architecture diagram lacks monitoring and alerting components. These are essential in production."

I hadn't thought about any of these. That 20-minute practice session taught me more than a week of reading.

My practice log:

The Trap of "Perfect AI Answers"

There was an unexpected side effect of using AI for practice: AI's answers were too perfect.

When I asked AI to design a recommendation system, it produced a 7-module, 4-layer-cache, 3-model masterpiece. Reading it made me feel like I was making great progress. In reality, it was a YouTube-scale architecture, not what you'd propose in a 45-minute interview.

My fix: Add constraints to the prompt.

Before each session, I started adding:

"Answer as a senior engineer designing a practical MVP that handles 1M DAU with horizontal scaling. No over-engineering."

The output became much more grounded and useful.

Phase 4: Sprint to the Finish (Days 61-90)

For the final month, I had AI run a daily "mock interview bootcamp."

Daily flow:
1. AI randomly picks a question from a curated list
2. I time myself: 45 minutes to draw architecture + write key design decisions
3. AI scores me across 5 dimensions:
- Functional coverage (completeness): 30%
- Architecture合理性 (component choices + module separation): 25%
- Scalability (handling growth): 20%
- Deep-dive responses (edge cases): 15%
- Communication clarity: 10%

By day 75, my average score went from 5 to about 7.5 out of 10.

Most valuable feedback I received:

Feedback 1: Capacity planning
AI pointed out: every one of my designs was "technically correct" but lacked quantified capacity planning. "You say 'use Redis for hot data.' What's the expected QPS? How much memory? These numbers are what interviewers actually want to hear."

This hit home. I started adding concrete numbers to every design: estimated QPS, storage requirements, bandwidth needs, node counts.

Feedback 2: Trade-off discussions
AI noted: "You always present one solution without discussing alternatives. Interviewers want to hear your decision-making process — what options you considered and why you chose this one."

I changed my approach. Now for every decision, I say: "I considered A, B, and C. I chose A because... and rejected B because..."

Feedback 3: System boundaries
AI pointed out: "Components work well individually in your diagram, but you haven't defined the interfaces and data flows between them. API contracts are the most overlooked yet most critical part of system design."

Day 90: The Honest Assessment

What I Actually Learned

• Distributed theory: From "knowing what CAP is" to "explaining why most systems choose AP + eventual consistency"
• Databases: From "having used MySQL sharding" to "designing shard strategies and picking consistent hashing"
• Caching: From "knowing Redis SET/GET" to "discussing cache penetration, breakdown, and avalanche prevention"
• Message queues: From "having used Kafka" to "comparing Kafka vs Pulsar vs RabbitMQ for different scenarios"
• Microservices: From "having written microservice code" to "designing service decomposition + API gateway selection"

What AI Did Well

• ✅ Instant feedback — the single most valuable feature traditional learning lacks
• ✅ Interview simulation — rare practice resource made accessible
• ✅ Blind spot detection — AI sees gaps you don't know you have
• ✅ Adaptive difficulty — questions adjust to your performance in real-time

What AI Couldn't Do

• ❌ Replace foundational reading — deep understanding still requires books and papers
• ❌ Guarantee accuracy — AI confidently fabricates incorrect "facts"
• ❌ Create real pressure — AI simulation ≠ real interview stress
• ❌ Judge business context — AI doesn't understand why a "technically suboptimal" solution might be the right business choice

The Workflow I Kept

After 90 days, my learning method is now fixed:

Read (book/docs) → Explain to AI in my own words → AI corrects + supplements → Quiz → Review mistakes

AI is positioned as a learning coach, not a knowledge delivery system. It doesn't save me time on "learning" — it improves the quality of learning.

Real Mistakes I Made

Mistake 1: AI Hallucinated Technical "Facts"

I once asked Claude about DynamoDB's Global Secondary Index write performance. It gave a detailed, professional-sounding explanation. When I checked AWS documentation, two key claims were wrong:

1. "GSI shares write capacity with the base table" — false, GSI has its own write capacity
2. "GSI is eventually consistent by default" — actually, GSI supports strongly consistent reads

If I'd brought these "facts" to an interview, I'd have been caught immediately.

Lesson: Always verify AI's technical claims against official documentation.

Mistake 2: Chasing "Standard Answers"

Early on, I tried to get AI to produce "the perfect design" and memorize it. But real interviews don't care about standard answers — they want to hear your thought process.

Lesson: Practice the process, not the answer.

Mistake 3: AI as My Only Learning Channel

For a while, I stopped reading books entirely and relied only on AI explanations. The result was fragmented knowledge — AI could explain "what consistent hashing is," but couldn't give me the context of "why DynamoDB and Cassandra implement it differently." Only reading papers and source code provides that depth.

Lesson: AI is a navigation tool, not the map. It's great for directions, but without the map, you never know what roads you're missing.

Mistake 4: Overestimating AI Practice Transfer

After 30 mock interviews with AI, I felt confident. My first real mock interview with a human? Complete disaster — nervous, lost my train of thought, forgot the structure I'd practiced.

Lesson: AI practice ≠ real practice. AI doesn't create pressure or stress.

Final Score

After 90 days, here's my honest assessment:

Actual knowledge gain: 7/10
I know substantially more. But real system design ability comes from building real systems.

AI as learning tool: 8/10
Exceeded expectations, especially the Feynman Technique + AI correction combo.

Interview readiness: 5/10
AI helped, but cannot replace real human mock interviews. Communication skills and handling pressure require real practice.

Advice for AI-Assisted Learners

If you're thinking about using AI for self-learning:

1. Diagnose first, plan second: Let AI test your baseline before making a study plan
2. AI is a coach, not a teacher: Active learning (explain to AI + AI quizzes) is 3x more effective than passive (AI lectures you)
3. Cross-verify everything: Check critical AI claims against official docs
4. Don't skip human practice: AI cannot replace real human interaction
5. Write your own notes: Your own notes are always more reliable than AI conversation history

What's Next

The 90-day plan is done, but the learning continues. I now have AI give me one new design question per week to keep sharp, and I'm finally reading DDIA cover to cover — with the foundation AI helped build, the reading is much more efficient.

Next step: applying this knowledge to a real project. I'm planning to refactor my personal blog from a monolith to microservices — and this time, I'm writing the code myself, without AI assistance. Not because AI can't help, but because I want to own this knowledge.

Written May 2026. All methods and conclusions are based on personal experience. If you've tried similar AI-assisted learning, I'd love to hear how it went.