These software architecture learning paths are designed for mid-level and senior developers preparing for Staff Engineer, Tech Lead, or Software Architect roles.
Each path groups lessons by real production challenge rather than publication date, so you learn what you need in the order that makes sense.
Whether you're troubleshooting microservices reliability, fixing data consistency issues, rethinking service boundaries, or learning to communicate architecture decisions, pick the track that matches your current pain point.
Build systems that stay up at night without you.
You're starting to own production reliability. Pages wake you up. Retries cascade. "It works on my machine" doesn't help when the dashboard is red.
This path takes you from setting SLOs to building circuit breakers, bulkheads, and shadow traffic validation. Ten lessons, each one a concrete guardrail you can deploy.
You'll learn to:
Define SLOs and track error budgets your team actually uses
Set up timeout chains that don't melt under pressure
Diagnose and fix retry storms before they cascade
Validate changes with shadow traffic before any major cutover
Lessons
Minutes
Next step: When your services are reliable, make sure the data underneath is too. Continue to Path 2.
Stop "why is data different?" incidents. Permanently.
Your queries are slow, and you're not sure why. Events go missing between services. Someone added a cache and now you have two sources of truth. Sound familiar?
This path covers the data layer from indexes to the outbox pattern. Nine lessons that turn consistency from an accident into a deliberate design choice.
You'll learn to:
Audit and fix slow queries using index analysis
Implement the outbox pattern for reliable event publishing
Design cache layers with explicit staleness budgets
Write idempotent operations that survive retries and replays
Lessons
Minutes
Next step: Your data is solid. Now make sure the services around it are drawn in the right places. Continue to Path 3.
Draw boundaries that survive your next reorg.
You're splitting a monolith. Or maybe you already did, and now you have a distributed monolith that's worse. Every deploy touches three teams. Every change breaks something downstream.
This path teaches you to think in boundaries, not boxes. Eleven lessons on where to cut, when to merge back, and how team structure shapes everything.
You'll learn to:
Evaluate whether a service split is justified or premature
Diagnose distributed monolith symptoms and plan a merge-first strategy
Align service boundaries to team boundaries deliberately
Design for reversibility in every major decision
Lessons
Minutes
Next step: You can design systems. Now learn to communicate those decisions so they stick. Continue to Path 4.
The architecture that stays in your head helps no one.
You have opinions about the system. Strong ones, probably. But when you try to explain why the team should change direction, eyes glaze over. Decisions get revisited. Context gets lost. Six months later, no one remembers why you chose Kafka over RabbitMQ.
This path is about the human side of architecture. Ten lessons on how to communicate decisions, run reviews, and write things down so future-you doesn't have to guess.
You'll learn to:
Run a 30-minute architecture review with your team
Write ADRs that capture the "why" behind every decision
Present tradeoffs clearly to stakeholders who aren't engineers
Build golden paths that encode good defaults across the org
Lessons
Minutes
Not sure where to start?
"I keep getting paged at night." Start with Path 1.
"Our queries are slow and data keeps getting out of sync." Start with Path 2.
"We split into microservices and now everything is harder." Start with Path 3.
"I have the technical skills but struggle to influence decisions." Start with Path 4.
How long does each software architecture learning path take?
Each path contains 9 to 11 lessons and takes roughly 60 to 80 minutes of total reading. Most readers finish one path in a week of commutes or lunch breaks. The lessons are designed to be read in sequence, but each one also stands on its own if you need to jump to a specific topic.
Do I need to be a senior developer to start these paths?
No. These learning paths are built for mid-level developers with 3 or more years of experience who are starting to think beyond individual tasks. If you've ever debugged a production incident, reviewed someone else's pull request, or wondered why a system was designed a certain way, you have enough context to get value from these lessons. Senior developers and team leads will also find practical tools they can apply immediately.
Which learning path should I start with?
It depends on what's hurting right now. If you're getting paged at night and reliability is your biggest concern, start with Path 1. If slow queries or data sync issues are eating your sprint time, go with Path 2. If your team split into microservices and things got harder instead of easier, Path 3 addresses exactly that. And if you have strong technical instincts but struggle to get buy-in or communicate decisions clearly, Path 4 is where you'll see the fastest return. If you're brand new to architecture thinking, I'd recommend Path 4 first, then Path 3.
What makes these paths different from a software architecture roadmap?
Most architecture roadmaps list skills and technologies you should learn. These paths are lesson-based. Each one walks you through a real production problem, gives you a concrete tool (a checklist, decision sheet, or runbook), and includes a hands-on challenge you can finish in 30 to 45 minutes. You're not checking boxes on a skills list. You're building judgment by working through the same tradeoffs architects face every week.
Are the lessons free?
Yes. Every lesson in all four paths is free to read on the web. If you want the lessons delivered to your inbox each week as they publish, you can subscribe to the Tech Architect Insights newsletter at no cost. There's also a free 5-day email crash course if you want a structured starting point before diving into the paths.
Can I use these lessons to prepare for a software architect interview?
Several readers have told me they used specific lessons during interview prep, particularly the ones on architecture decision records, tradeoff analysis, system design boundaries, and the 30-minute architecture review. Paths 3 and 4 together cover the two areas interviewers test most: how you think about system design and how you communicate your reasoning. That said, these paths are designed for the job, not just the interview. The patterns and tools here are things you'll use the first week in the role.
Every week, I publish one new lesson on a real architecture problem: concrete failure modes, measurable outcomes, and defaults you can copy. No fluff.
Or start with the free 5-day crash course: From Developer to Architect — five focused lessons on mindset, tradeoffs, and communication.
These paths are built from 40 weekly issues of Tech Architect Insights, written by Bogdan Colța. Every lesson is grounded in 17+ years of production experience. No theory without practice.