Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path →
18 stations. 3 tracks. From cloud fundamentals and data through the Well-Architected pillars, scalability, resilience and cost, to requirements discovery, decision records and stakeholder craft — become the engineer who turns a business problem into a system that ships.
18 stations on 3 ladders, in order — each rung is written assuming the one above it. Mark them off as you go; your progress is saved in this browser.
F1 · Beginner · 45 min
A solutions architect sits between the business problem and the technical system, fluent in both. Learn what the role actually is — not the most senior coder, but the person who owns the shape of a solution, its trade-offs and its "why" — and the difference between a solutions, enterprise and cloud architect.
Build itA stakeholder asks for "a microservices platform." What questions do you ask before that word survives the meeting?
✓ CheckpointExplain a technical trade-off you made to someone who controls the budget, using consequences rather than technologies.
F2 · Beginner · 55 min
Modern architecture is cloud architecture. Learn the core building blocks — compute, storage, networking, identity — the managed-vs-self-hosted decision, regions and availability zones, and the shared-responsibility model, so you can compose services into a system instead of reinventing each one from raw servers.
Build itFor a new app, list which pieces you’d take as managed services and which you’d run yourself — and why.
✓ CheckpointDraw the shared responsibility line for a managed service you use, and name what you wrongly assumed the provider handles.
F3 · Intermediate · 55 min
Every architecture is a network with a security boundary. Learn VPCs and subnets, load balancing and DNS, and the identity layer — IAM, roles, least privilege — plus where encryption in transit and at rest belongs, so the system you draw is one a security review will actually approve.
Build itSketch the network boundary for a public API that talks to a private database. What must never be reachable from the internet?
✓ CheckpointExplain why a security group is not least privilege, and name what an over-broad IAM role actually costs you on a bad day.
F4 · Intermediate · 50 min
Choosing the right compute and storage shape is half of architecture. Learn the spectrum — VMs, containers, serverless — and the storage families — object, block, file — with the cost, latency and operational trade-offs of each, so "just use Lambda" or "just use S3" becomes a reasoned choice, not a reflex.
Build itA workload runs 30 seconds once an hour. Argue serverless vs a VM on cost and cold-start, and pick one.
✓ CheckpointJustify serverless over containers for one workload and the reverse for another. Same answer for both means you have a default, not a reason.
F5 · Intermediate · 55 min
Data outlives every service around it, so its shape is the most consequential choice you make. Learn SQL vs NoSQL, when each fits, OLTP vs OLAP, caching, and the CAP trade-offs that decide whether your system stays consistent or available when the network splits — because you cannot have both.
Build itA team defaults to one database for everything. Give two workloads where that’s wrong and what you’d pick instead.
✓ CheckpointExplain why putting analytical queries on your transactional database works fine right up until it does not.
F6 · Intermediate · 50 min
An architecture that lives only in a diagram drifts from reality within a week. Learn infrastructure as code — Terraform/OpenTofu, state, modules, plan-and-apply discipline — so the system you design is version-controlled, reviewable and reproducible, and the diagram and the running cloud stay the same thing.
Build itSomeone hand-edits a resource in the console that IaC also manages. Explain the drift this causes and how the next apply behaves.
✓ CheckpointExplain what breaks when two engineers apply Terraform at the same time, and what the state file is really protecting.
6 rungs · ~6h · ends at Migration Strategies.
T1 · Intermediate · 55 min
Cloud providers distilled decades of architecture into a small set of pillars — operational excellence, security, reliability, performance, cost, and sustainability. Learn to use them as a review lens: a structured set of hard questions you ask about any design to find the weak pillar before production does.
Build itA design is fast and cheap but has one region and no backups. Which pillars does it fail, and what’s the minimum fix?
✓ CheckpointName the weakest pillar in a system you know, and the pillar you deliberately traded away to strengthen it.
T2 · Intermediate · 55 min
Design for the load you’ll have, not the load you have. Learn horizontal vs vertical scaling, statelessness, load balancing and the database as the usual bottleneck, plus high-availability patterns — redundancy, multi-AZ, no single point of failure — so growth is a config change, not a rewrite.
Build itA design puts session state in the app server’s memory. Explain why that blocks horizontal scaling and how you’d fix it.
✓ CheckpointExplain why statelessness is what makes horizontal scaling possible, and where the state actually went.
T3 · Advanced · 50 min
Everything fails eventually; resilient systems degrade instead of collapsing. Learn timeouts, retries and circuit breakers, graceful degradation, and disaster recovery defined by two numbers — RTO and RPO — plus the backup, replication and failover strategy that actually meets them when a whole region goes dark.
Build itThe business says "zero downtime, zero data loss." Explain the cost reality behind RTO=0 and RPO=0 and how you’d negotiate it.
✓ CheckpointState an RTO and RPO you would commit to in writing, and describe the backup test that would prove you can meet them.
T4 · Advanced · 50 min
In the cloud, architecture is a monthly bill, and the architect owns it. Learn the FinOps mindset — right-sizing, reserved vs spot capacity, storage tiering, and killing idle waste — plus how to make cost a first-class design constraint so the elegant system you drew doesn’t quietly become the one finance asks you to defend.
Build itA dev/test environment runs 24/7 but is used 40 hours a week. Estimate the waste and the simplest fix.
✓ CheckpointExplain why cost is a design input rather than a cleanup task, and name an architecture choice that is cheap now and expensive at 10x.
T5 · Advanced · 55 min
Real systems are made of parts that must talk. Learn the integration toolkit — synchronous APIs and gateways, asynchronous queues and events, webhooks, and the event-driven patterns that decouple producers from consumers — and when each is right, so services stay independent instead of collapsing into a distributed monolith.
Build itTwo services are tightly coupled through synchronous calls and fail together. Redesign the seam so one can be down without the other.
✓ CheckpointJustify a queue over a synchronous API for one integration, and be honest about the debugging complexity you just bought.
T6 · Advanced · 50 min
Most architecture work is changing a system that already exists and can’t stop. Learn the migration playbook — the 6 Rs (rehost, replatform, refactor…), the strangler-fig pattern for retiring a monolith incrementally, and how to move data and cut over without the big-bang rewrite that so reliably ends in disaster.
Build itA 10-year-old monolith must move to the cloud with no downtime. Sketch a strangler-fig plan for the first slice.
✓ CheckpointPick one of the 6 Rs for a real legacy system and defend it — including why the more ambitious option is wrong here.
6 rungs · ~5h · ends at The Architect Career.
P1 · Advanced · 50 min
The most expensive architecture mistakes are made before any diagram exists. Learn to run discovery — separate functional from non-functional requirements, pin down the real numbers behind "fast" and "scalable," surface constraints and hidden assumptions — so you design for the actual problem, not the one that was easiest to state.
Build itA client says "it must be scalable." Write the three questions that turn that word into a number you can design against.
✓ CheckpointTurn “it needs to be fast” into a number with a percentile attached, and say who suffers when it is missed.
P2 · Advanced · 45 min
An architecture is a stack of decisions, and the reasoning behind them is worth more than the diagram. Learn to write Architecture Decision Records — the choice, the alternatives, the trade-offs, the context — so future teams (and future you) know why the system is the way it is, and can revisit a decision instead of cargo-culting it.
Build itWrite a one-paragraph ADR for choosing PostgreSQL over a document store — including the trade-off you knowingly accepted.
✓ CheckpointWrite the alternative you rejected into an ADR as convincingly as the one you chose. If you cannot, you did not evaluate it.
P3 · Advanced · 50 min
At the architecture level, security and compliance are design constraints, not a final gate. Learn threat modeling, data residency and privacy regimes (GDPR, SOC 2, HIPAA), and how to design defense in depth and auditability in from the start — because retrofitting compliance onto a finished system is the expensive way to learn this lesson.
Build itA system stores EU user data on US servers. Name the compliance problem and the architectural change that resolves it.
✓ CheckpointExplain why defense in depth assumes your outer layer will fail, and name the layer you are currently relying on alone.
P4 · Advanced · 50 min
An architecture no one buys into never gets built. Learn to communicate a design to every audience — a napkin sketch for an exec, a sequence diagram for engineers, a cost model for finance — to run a design review that surfaces objections early, and to sell the trade-offs so the room owns the decision with you.
Build itYou must explain the same system to a CFO and a senior engineer. Describe how the two explanations differ — and what stays the same.
✓ CheckpointDraw the same system twice — once for an executive, once for the implementing team — and say what you left out of each.
P5 · Advanced · 45 min
Sometimes one cloud isn’t the answer — or isn’t allowed. Learn the real reasons for multi-cloud and hybrid (regulation, acquisitions, avoiding lock-in, on-prem legacy), the heavy cost in complexity they carry, and how to weigh portability against depth so "multi-cloud" is a deliberate strategy, not resume-driven architecture.
Build itA team wants multi-cloud "to avoid lock-in." Argue the honest cost of that choice and when it’s actually worth paying.
✓ CheckpointState the real reason a multi-cloud strategy is on the table, and price the complexity it adds against the lock-in it avoids.
P6 · Advanced · 45 min
The architect’s influence comes from trust, not authority. Learn how the role grows — staying technical enough to be credible while zooming out to systems and orgs, choosing between the solutions, enterprise and cloud-architect paths, and the discipline of leaving room for the teams who build it to make real decisions of their own.
Build itYou could specify every detail or leave room for the team. Explain the trade-off and where you’d draw the line.
✓ CheckpointExplain how an architect with no authority gets a design adopted, and why being right is not sufficient.
The common questions before you start — how long it takes, whether to follow it in order, and how it stays current.
It runs 18 stations across 3 tracks — roughly ~17h of focused learning, plus the time you spend actually building. It is self-paced, so most people work through it over a few weeks, an evening or a single station at a time.
The tracks are ordered so each station builds on the one before, and following them start to finish is the intended path. But every station also stands alone — if you already have the foundations, jump straight to the part you need.
Yes. The whole roadmap, and every handbook, lab, and challenge it links to, is free and open — no sign-up and no paywall.
It teaches the durable fundamentals of the role first, then the tooling and the AI-era shifts on top — so most of it stays relevant as individual tools churn, and it is revised as the role itself changes.
Anyone stepping into or leveling up in the Solutions Architect role — whether you are switching in, early-career, or a senior filling gaps. Start where you are; the ladder shows what is left.
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.