Java Backend Roadmap 2027

Four tracks you learn together… and one project that grows with you.

Content version 2026-10-19 · ameenabozaid.com/roadmaps/java-backend-2027/ · A draft open to review. The stages describe growing responsibility; professional roles are proven through practice and impact, not checkboxes.

The master roadmap: six stages and four tracks

AI — Use AI to learn, reason, implement, and review from day one, and later build evaluated AI features into the product.
Java Backend & technical foundations — Understand, write, test, debug, and operate software.
Business, design & delivery — Understand the domain and the user's need, choose a suitable solution and design, and deliver value. Architecture and business understanding both belong to this track.
Communication & professional work — Explain, agree, collaborate, document, and lead as your responsibility grows.

	AI	Java Backend	Business, design & delivery	Communication & professional
01 · BeginnerSteps 01–04 · Outcome: An in-memory course program	Explanations, hints, and review	Java, OOP, Git, and tests	Enrollment rules and simple responsibilities	A clear question and an explained decision
02 · Junior foundationsSteps 05–07 · Outcome: A backend with persistent data	Data-model critique and an IDE assistant	SQL, HTTP, and Spring Boot	ERD and API contracts	Documentation and work with Frontend and QA
03 · Capable JuniorSteps 08–10 · Outcome: A deployed student journey	Review, tests, and a bounded agent	Security, Docker, and CI/CD	Permissions, quality, and releases	Demo and runbook
04 · Mid-levelSteps 11–14 · Outcome: A complete feature that tolerates failure	Analysis and model integration	Concurrency, performance, and integrations	Consistency, payments, and value	Ownership, estimation, and trade-offs
05 · Preparing for Senior responsibilitiesSteps 15–18 · Outcome: An important part you can operate	RAG and tool calling	Multi-tenancy and observability	SaaS, SLOs, and scaling	Leadership and mentoring
06 · Staff / Architect and beyondSteps 19–21 · Outcome: Impact across teams	Operating, evaluating, and enabling teams	Platform and deep specialization	Strategy and economics	Influence and growing leaders

Stage 1 — Beginner: a small Java program you understand · Steps 01–04

Stage goal: Start using AI and build a foundation that helps you understand and review, with an in-memory program that manages courses, students, and enrollments.

Exit evidence: You run the program and explain its behavior, add a new rule, and diagnose a bug and prove the fix with a test.

01 Your environment and a clear question

Where do we apply this in the platform? Run a Java program that shows course data, and define the teacher, student, course, and enrollment as the platform's first scope.

AI: A learning assistant

What will you learn?: ChatGPT or Claude basics: a clear goal, context, follow-up questions, and the limits of trust and privacy.
Why?: You use it to explain, practice, and review from day one.
What's the evidence of learning?: You summarize a concept in your own words, try an example, and verify the answer.

Java Backend: Your environment and understanding a program

What will you learn?: The JDK, an IDE such as IntelliJ IDEA, the terminal, files, running a Java program, and tracing inputs and outputs.
Why?: You set up an environment to experiment in and understand the write-and-run cycle.
What's the evidence of learning?: You run a program that shows course data, change the inputs, and explain the result.

Business, design & delivery: Understanding the journey project

What will you learn?: The user, the problem, the goal, and the scope: teacher, student, course, and enrollment; stating your assumptions.
Why?: You connect learning to a real need and start with a small scope.
What's the evidence of learning?: You write a short description of the platform and three questions you need the teacher to answer.

Communication & professional: The clear question

What will you learn?: Describing the goal, what you tried, and the expected versus actual result; basic English technical vocabulary.
Why?: You get useful help and reduce misunderstanding.
What's the evidence of learning?: You write a question someone else can understand and reproduce.

02 Java basics and problem solving

Where do we apply this in the platform? The enrollment-eligibility rule: who can enroll in a course, with written success and rejection cases that match the program's behavior.

AI: How to learn with AI

What will you learn?: Asking for a hint, breaking the problem down, explaining one step, then verifying and trying on your own.
Why?: You turn help into an ability you can use yourself.
What's the evidence of learning?: You solve a similar exercise and explain the solution after the help ends.

Java Backend: Java basics and problem solving

What will you learn?: Types, variables, conditions, loops, methods, strings, arrays, scope, and the debugger.
Why?: You express the platform's rules in code and follow how they run.
What's the evidence of learning?: You implement a simple enrollment-eligibility rule, trace a wrong condition, and fix it.

Business, design & delivery: Turning a rule into behavior

What will you learn?: Inputs and outputs, pseudocode, success and rejection cases, and concrete acceptance examples.
Why?: You define the required behavior before implementing it.
What's the evidence of learning?: You write cases for an eligible and an ineligible student, and the program's results match them.

Communication & professional: Explaining your thinking

What will you learn?: Explaining the steps of a solution, writing down assumptions, and clearly stating what you don't understand.
Why?: Others can follow your logic and help you.
What's the evidence of learning?: You explain the enrollment rule and a counterexample in two minutes.

03 Modeling code in Java

Where do we apply this in the platform? An in-memory model of students, courses, and enrollments that prevents duplicate enrollment and respects course capacity.

AI: Exercises with gradual help

What will you learn?: Examples, exercises, and edge cases; predicting the result before asking for an explanation.
Why?: You uncover gaps in understanding instead of just following a ready answer.
What's the evidence of learning?: You predict the output and explain any difference between expected and actual.

Java Backend: Modeling code in Java

What will you learn?: OOP, encapsulation, composition, interfaces, collections, generics, and exceptions; data-structure and complexity basics.
Why?: You represent students, courses, and enrollments and choose how to work with them.
What's the evidence of learning?: You build an in-memory model that prevents duplicate enrollment, add course capacity, and test it.

Business, design & delivery: Clear responsibilities and rules

What will you learn?: Entities, invariants, separating business rules from the user interface, and a simple design that can change.
Why?: You know where the enrollment rule lives and what is affected when it changes.
What's the evidence of learning?: You justify where the capacity rule lives and change it without copying it to several places.

Communication & professional: Explaining decisions

What will you learn?: Explaining what each part is responsible for and why you chose a collection or an interface, plus a simple alternative.
Why?: The code becomes open to discussion and review.
What's the evidence of learning?: You give a short walkthrough, and a colleague can add a new rule.

04 Developer tools and early testing

Where do we apply this in the platform? The platform's first repository: a build from a clean checkout, a test that prevents duplicate enrollment, and a reviewable PR.

AI: Reviewing an existing attempt

What will you learn?: Showing your attempt and asking AI about a specific flaw or alternative, then examining the diff and the suggestions.
Why?: You learn to evaluate a review and avoid accepting changes you don't understand.
What's the evidence of learning?: You accept or reject a suggestion based on a test and an explanation.

Java Backend: Developer tools and early testing

What will you learn?: Git, commits, branches, pull requests, Maven, and JUnit; refactoring and reading stack traces.
Why?: You keep the project's history and change code with confidence.
What's the evidence of learning?: The project builds from a clean checkout, and a test fails before the duplicate-prevention fix and passes after it.

Business, design & delivery: Delivering a small change

What will you learn?: Breaking down the task, acceptance criteria, a definition of done, and separating behavior changes from structural improvements.
Why?: You finish a reviewable unit and know when it is done.
What's the evidence of learning?: A small task with code, tests, and acceptance criteria that are met.

Communication & professional: Code review and documentation

What will you learn?: A short README, a clear commit and PR, requesting review, and responding to comments.
Why?: Someone else can run the project and understand the change.
What's the evidence of learning?: A colleague runs it from the README, reviews the PR, and knows why the behavior changed.

Stage 2 — Junior foundations: backend, APIs, and a database · Steps 05–07

Stage goal: Turn the program into a backend with persistent data and APIs for courses, lessons, and enrollment.

Exit evidence: You trace a request to the database, justify the model and the API contract, change a requirement and test it, and someone else can use your documentation.

05 Databases and data modeling

Where do we apply this in the platform? Move students, courses, and enrollments to PostgreSQL, with an Enrollment table and constraints that prevent duplicates.

AI: Critiquing the data model

What will you learn?: Comparing schema alternatives, raising cases that expose missing constraints, and generating test data.
Why?: You test the model's assumptions before relying on it.
What's the evidence of learning?: You review a suggestion and prove your choice with data and an experiment.

Java Backend: SQL and the database

What will you learn?: PostgreSQL, tables, keys, constraints, joins, transactions, index basics, JDBC, then migrations.
Why?: You store students, courses, and enrollments and enforce their consistency rules.
What's the evidence of learning?: Data persists across runs, a forbidden duplicate fails, and an incomplete operation is rolled back.

Business, design & delivery: Data modeling

What will you learn?: ERD, cardinality, normalization, transaction boundaries, and rules for deletion and change.
Why?: You turn the domain into a model that serves its use and stays consistent.
What's the evidence of learning?: You justify the Enrollment table and test enrollment, deletion, and failure.

Communication & professional: Documenting and discussing a model

What will you learn?: Explaining relationships and constraints, naming terms, and recording open questions.
Why?: The team interprets the data the same way.
What's the evidence of learning?: Someone else reads the diagram and writes a correct query for a student's enrollments.

06 The web and API contracts

Where do we apply this in the platform? An API contract for listing courses, enrolling, and rejection cases, agreed before implementation.

AI: Understanding tools and requests

What will you learn?: Interpreting HTTP requests, responses, and errors, and proposing specific diagnostic experiments.
Why?: You learn to trace a request and verify hypotheses.
What's the evidence of learning?: You explain a failed request and prove the cause instead of settling for the model's guess.

Java Backend: The web and API contracts

What will you learn?: Client/server, an introduction to DNS and TCP/TLS, HTTP, REST, JSON, status codes, headers, and curl or Postman.
Why?: You understand how the platform's interface talks to the backend and how requests behave.
What's the evidence of learning?: You write and try an enrollment request and explain the correct and incorrect responses.

Business, design & delivery: Use cases and API contracts

What will you learn?: Actors, scenarios, request/response, errors, pagination, and acceptance criteria.
Why?: The meaning of each operation is clear to the interface and to testing.
What's the evidence of learning?: You define the contract for listing courses and enrolling, including rejection cases, before implementation.

Communication & professional: Working with Frontend and QA

What will you learn?: Clarifying questions, example requests and results, and describing a reproducible bug.
Why?: You agree on behavior and reduce rework.
What's the evidence of learning?: A colleague implements a client or a test from the contract without guessing.

07 Spring Boot and data storage

Where do we apply this in the platform? A Spring Boot backend with APIs for courses, lessons, and enrollment, and documentation someone else can use.

AI: A first coding assistant in the IDE

What will you learn?: File context, specific instructions, a small suggestion or change, reviewing the diff, and running the tests.
Why?: You speed up implementation while understanding what changed.
What's the evidence of learning?: You implement a bounded endpoint, explain every change, and catch an unsuitable suggestion.

Java Backend: Spring Boot and data storage

What will you learn?: Dependency injection, configuration, controllers, services, DTOs, validation, error handling, and Spring Data JPA, with an understanding of SQL, migrations, and API docs.
Why?: You turn the program into a usable backend.
What's the evidence of learning?: APIs for courses, lessons, and enrollment, and you trace a request from the controller to the database.

Business, design & delivery: Organizing the application

What will you learn?: Separating responsibilities and simple module boundaries, domain rules, the use-case flow, and a feature's definition of done.
Why?: You control the impact of a change and keep behavior clear.
What's the evidence of learning?: Changing an enrollment rule affects only the expected parts, and you prove it with a test.

Communication & professional: Demo and feature review

What will you learn?: Showing the user journey, explaining the decision, documenting the API, and taking feedback.
Why?: The team confirms the meaning and the result before expanding.
What's the evidence of learning?: Someone uses the API from the documentation, and you absorb a change request and explain it.

Stage 3 — Capable Junior: a secure, deployed, maintainable application · Steps 08–10

Stage goal: Add accounts, permissions, lessons, quizzes, and results, and deliver a complete student journey on a deployed environment.

Exit evidence: You deliver a small feature from understanding the requirement through deployment and follow-up, and you know when you need help or review.

08 Accounts and permissions

Where do we apply this in the platform? Accounts and roles: a student sees only their own enrollments and a teacher edits only their own courses, even with a direct request.

AI: Security review

What will you learn?: Using AI to suggest misuse cases and review specific settings or code, with independent verification.
Why?: You widen the set of cases you examine.
What's the evidence of learning?: You find an unauthorized-access scenario and prove it is blocked with a test.

Java Backend: Accounts and permissions

What will you learn?: Spring Security, authentication, authorization, password hashing, sessions/tokens, resource ownership, secrets, and CORS/CSRF depending on the login mechanism.
Why?: You protect the platform's accounts, content, and operations.
What's the evidence of learning?: A student can't read another student's enrollment and a teacher can't edit someone else's course, even with a direct request.

Business, design & delivery: Access rules and risks

What will you learn?: A matrix of roles, ownership, and access conditions; least privilege; and simple threats.
Why?: Permissions follow the platform's rules and cover the required records.
What's the evidence of learning?: You turn every access rule into a success case, a rejection case, and an acceptance test.

Communication & professional: Communicating risk

What will you learn?: Explaining impact, priority, and reproduction steps, and avoiding sharing sensitive data.
Why?: The team handles the problem clearly.
What's the evidence of learning?: You write an issue report that shows who is affected and how to verify the fix.

09 Testing strategy and quality

Where do we apply this in the platform? Tests for the lesson, quiz, and result journey that catch any grading bug before it is fixed.

AI: Generating useful test cases

What will you learn?: Boundary cases, negative cases, fixtures, critiquing assertions, and examining suggested tests.
Why?: You expand coverage around real risks.
What's the evidence of learning?: A suggested test exposes a real defect, and you explain what it proves and what it doesn't.

Java Backend: A practical testing strategy

What will you learn?: JUnit, Mockito when needed, integration tests, Testcontainers, Spring test support, and core journey tests.
Why?: You verify business rules and the real connection to the database.
What's the evidence of learning?: The lesson, quiz, and result journey works, and a grading defect fails the test before it is fixed.

Business, design & delivery: Quality and evidence of done

What will you learn?: A practical test pyramid, regression risks, acceptance tests, and release criteria.
Why?: You tie testing to behavior that matters to the user.
What's the evidence of learning?: Every critical rule has a suitable test, and a requested change doesn't break the core journey.

Communication & professional: Collaborating on quality

What will you learn?: Bug reports, review with QA, explaining the limits of testing, and documenting the fix decision.
Why?: Bugs become easy to reproduce and prioritize.
What's the evidence of learning?: A colleague reproduces a defect from your report and verifies its fix.

10 Operations, deployment, and a first release

Where do we apply this in the platform? A complete student journey on a deployed environment: sign in, choose a course, enroll, take a lesson and a quiz, and see the result.

AI: A small agent task

What will you learn?: A clear scope of files and tools, checkpoints, reading the diff, limited permissions, and verifying it runs.
Why?: You delegate a bounded step and keep the ability to review it.
What's the evidence of learning?: The agent completes a task such as run setup or documentation, and you verify it from a clean environment.

Java Backend: Operations and deployment

What will you learn?: Linux basics, Docker and Compose, environment configuration, CI/CD, secrets, health checks, logs, migrations, and backup/restore.
Why?: You ship the service, follow it, and have a way to recover.
What's the evidence of learning?: It runs from a clean environment with an automatic pipeline; you deploy an update and restore a test data backup.

Business, design & delivery: A first deliverable release

What will you learn?: MVP, prioritization, a release checklist, migrations, rollback, and a simple operating plan.
Why?: You deliver a complete student journey instead of separate features.
What's the evidence of learning?: Sign-in, choosing a course, enrolling, a lesson, a quiz, and a result on a deployed environment.

Communication & professional: Demo, handover, and diagnosis

What will you learn?: Showing a user journey, release notes, a runbook, and an update about a blocker or an incident.
Why?: Users and the team know what was done and what needs attention.
What's the evidence of learning?: Someone runs the service and follows the diagnostic steps for a problem from your documents.

Stage 4 — Mid-level: owning a complete feature and handling complexity · Steps 11–14

Stage goal: Handle business rules, concurrency, performance, integrations, and failure with more independence, and build a first useful AI feature for teachers.

Exit evidence: You own a medium-sized feature from requirements to operation, handle integrations and failure cases, and explain your trade-offs, with review matched to the risk.

11 Concurrency and consistent rules

Where do we apply this in the platform? Protect the last seat in a course from concurrent enrollments, with a test that proves the result.

AI: AI as an analysis partner

What will you learn?: Change-impact analysis, design alternatives, critiquing assumptions, and providing context from specific files.
Why?: You test your idea before and during implementation.
What's the evidence of learning?: You pick an alternative based on a constraint and an experiment, and document why you rejected another.

Java Backend: Deeper Java and concurrency

What will you learn?: Streams, immutability, JVM/memory basics, threads, executors, synchronization, race conditions, virtual threads, and complexity analysis.
Why?: You understand how code behaves under concurrency and choose suitable tools.
What's the evidence of learning?: You reproduce concurrent enrollments that break capacity, then fix them and prove the behavior.

Business, design & delivery: Consistent platform rules

What will you learn?: Invariants, transaction boundaries, optimistic/pessimistic locking, and what success means under contention.
Why?: The last seat in a course is never sold to more than one student.
What's the evidence of learning?: A concurrent test proves the result, and you explain the cost of your choice.

Communication & professional: Ownership and estimation

What will you learn?: Breaking down a feature, identifying dependencies and risks, and updating the estimate as you learn.
Why?: The team relies on a clear commitment.
What's the evidence of learning?: You deliver a small plan and flag early when new information changes it.

12 Performance and non-functional requirements

Where do we apply this in the platform? Speed up course and progress listings with a specific measurement, and protect lesson files from unauthorized access.

AI: Investigating with evidence

What will you learn?: Analyzing query plans and logs with sensitive data removed, with AI's help, and proposing experiments.
Why?: You speed up the investigation.
What's the evidence of learning?: You measure before and after the change and separate the hypothesis from the proven cause.

Java Backend: Data and content performance

What will you learn?: EXPLAIN, indexes, N+1, fetch strategies, pagination, connection pools, k6, Redis when needed, object storage, and signed URLs.
Why?: Showing courses, progress, and content stays practical as data grows.
What's the evidence of learning?: You improve a slow endpoint with a specific measurement and prove that access to an unauthorized file is blocked.

Business, design & delivery: Non-functional requirements

What will you learn?: Latency, throughput, data volumes, storage cost, cache invalidation, and the content-access policy.
Why?: "Fast" and "scalable" become requirements you can check.
What's the evidence of learning?: You define a target load and an acceptable result, and test both.

Communication & professional: Presenting results

What will you learn?: A short performance report and an explanation of the trade-offs.
Why?: Decisions are revisited based on evidence.
What's the evidence of learning?: You show the improvement, its cost, and the limits of the test.

13 Integrations and background jobs

Where do we apply this in the platform? Payments and notifications: a duplicate payment webhook doesn't duplicate the enrollment, and an email outage doesn't lose the job.

AI: An agent builds a bounded feature

What will you learn?: Project instructions, checkpoints, file and tool limits, reviewing changes, and verifying acceptance criteria.
Why?: You delegate larger work while keeping control.
What's the evidence of learning?: You detect a deviation from the rules and correct it before delivery.

Java Backend: Integrations and background jobs

What will you learn?: HTTP clients, timeouts, retries/backoff, idempotency, webhooks, scheduling, RabbitMQ for example, DLQs, and an introduction to the outbox pattern.
Why?: Payments and notifications tolerate delay, duplication, and failure.
What's the evidence of learning?: A duplicate payment webhook doesn't duplicate the enrollment or the financial effect, and an email outage doesn't lose the job.

Business, design & delivery: The payment and enrollment journey

What will you learn?: Order, payment, and enrollment states; refunds; reconciliation; and separating financial facts from success messages.
Why?: Payment success, enrollment, and notification are not one operation that is automatically guaranteed.
What's the evidence of learning?: You map and test successful, failed, delayed, and duplicate payment paths.

Communication & professional: Working with external parties

What will you learn?: Reading integration docs, asking precise questions, and documenting incidents and the limits of responsibility.
Why?: An integration depends on more than one team and system.
What's the evidence of learning?: You file a support request with a correlation ID, steps, and the expected result.

14 A first AI feature in the product

Where do we apply this in the platform? Draft quiz questions generated by AI and reviewed by the teacher, who can edit or reject them, with quality, cost, and latency measured.

AI: A first model integration in the product

What will you learn?: Model APIs, prompts/templates, tokens, context limits, structured outputs, streaming, timeouts, budgets, and a small evaluation set; Spring AI is a Java option.
Why?: You add real help for teachers.
What's the evidence of learning?: Generating a draft of questions the teacher reviews, with quality, cost, and latency measured and failures handled.

Java Backend: Operating an AI integration

What will you learn?: Key management, client integration, output validation, rate limiting, saving job state, and monitoring calls.
Why?: A model call stays part of a service you can operate.
What's the evidence of learning?: A provider outage or invalid returned JSON doesn't break the teacher's journey.

Business, design & delivery: Defining the feature's value

What will you learn?: Defining the user and the desired outcome, a manual baseline, the review workflow, and a success criterion.
Why?: You test whether AI saves time while keeping acceptable quality.
What's the evidence of learning?: A comparison on fixed examples shows the feature's benefit and where it needs review.

Communication & professional: Clarifying the output's limits

What will you learn?: Presenting the draft and its assumptions and asking for the user's assessment.
Why?: Users know what needs review.
What's the evidence of learning?: The teacher can edit and reject the output and report a specific defect.

Stage 5 — Preparing for Senior responsibilities: designing and operating parts that matter · Steps 15–18

Stage goal: Handle more ambiguity and risk, and improve both the system and the team; add a content assistant and permissions, and study SaaS, reliability, and distribution when they are needed.

Exit evidence: You own an important part across design, implementation, and operation, reduce its risks, guide others, and work with incomplete requirements. Doing this with a real team and real users is a core part of proving it.

15 A content-grounded assistant

Where do we apply this in the platform? An assistant that answers students only from the course content they are allowed to access, with citations and tests that prevent leaks.

AI: A content-grounded course assistant

What will you learn?: Embeddings, chunking, retrieval, metadata filtering, pgvector for example, RAG, citations, and evaluating retrieval and answers separately.
Why?: Students ask about content they are allowed to see.
What's the evidence of learning?: Known and out-of-scope questions, and tests that prevent retrieving data from an unauthorized student or course.

Java Backend: Search and retrieval architecture

What will you learn?: Ingestion jobs, parsing, indexing, updating and deleting indexes, metadata, and module boundaries.
Why?: The assistant's content stays consistent with current content and permissions.
What's the evidence of learning?: Editing a lesson or revoking a permission is reflected in retrieval according to a documented policy.

Business, design & delivery: Boundaries of authority and trust

What will you learn?: Threat modeling, prompt injection, source and refusal policies, and authorization before retrieval and execution.
Why?: Content or the model can't change the system's permission rules.
What's the evidence of learning?: Adversarial tests that try to leak content or execute embedded instructions are rejected.

Communication & professional: Communicating quality and risk

What will you learn?: Explaining what was measured and what wasn't, the feature's limits, and a gradual rollout plan.
Why?: A clear launch decision.
What's the evidence of learning?: You present successes, failures, and the criteria for stopping or improving the feature.

16 Architecture and turning the platform into SaaS

Where do we apply this in the platform? The platform serves centers and teachers with isolated data, plans and subscriptions, and a gradual migration plan.

AI: Architecture review with AI

What will you learn?: Critiquing boundaries, dependencies, and migration plans, and comparing scenarios.
Why?: You widen the alternatives you examined.
What's the evidence of learning?: An architectural decision backed by constraints and an experiment that you can defend without going back to the model's answer.

Java Backend: Architecture and multi-tenancy

What will you learn?: Modular monolith, practical DDD, bounded contexts, dependency boundaries, isolation strategies, tenant context, tenant-aware queries/cache/jobs, and isolation tests; Spring Modulith is a helpful option.
Why?: You serve teachers and centers with clear data and boundaries.
What's the evidence of learning?: One center can't reach another center's data through the API, files, jobs, or cache, with tests.

Business, design & delivery: Turning the platform into SaaS

What will you learn?: Tenants, memberships and roles, plans/entitlements, quotas, onboarding, support and operations, and the shared-versus-dedicated decision.
Why?: The product model differs from a single teacher's platform.
What's the evidence of learning?: A context map, an ADR, a gradual migration plan, and acceptance tests for every plan.

Communication & professional: Leading a design discussion

What will you learn?: RFC/ADR, listening to objections, and facilitating a decision.
Why?: Important decisions need shared understanding.
What's the evidence of learning?: The discussion ends with a decision, its reasons and risks, and an owner for follow-up.

17 Reliability and incident management

Where do we apply this in the platform? Monitor the platform with metrics, logs, and traces, and run an exercise of a failing external dependency and service recovery.

AI: AI in operational investigation

What will you learn?: Summarizing signals and failure hypotheses from controlled context and verifying them with measurements.
Why?: You speed up diagnosis and keep a record of the evidence.
What's the evidence of learning?: You confirm or rule out hypotheses with experiments and real indicators.

Java Backend: Observability and reliability

What will you learn?: Metrics, logs, traces, OpenTelemetry, Micrometer, Prometheus/Grafana, profiling/JFR, load tests, graceful degradation, and backup/restore drills.
Why?: You know the impact of failures and restore service.
What's the evidence of learning?: Injecting a failure into an external dependency, detecting it, reducing its impact, and restoring service to a defined target.

Business, design & delivery: SLOs and incident management

What will you learn?: SLIs/SLOs, error budgets, capacity, RTO/RPO, runbooks, postmortems, and prioritizing reliability work.
Why?: You balance feature development with service stability.
What's the evidence of learning?: A documented incident exercise with follow-up actions that have owners and dates.

Communication & professional: Leading an incident and mentoring a colleague

What will you learn?: Splitting the investigation, updating stakeholders, separating facts from hypotheses, and blameless guidance.
Why?: Less confusion and better team learning.
What's the evidence of learning?: A colleague takes over part of the investigation using your explanation and the runbook.

18 Distributed systems and scaling decisions

Where do we apply this in the platform? An assistant that reads a student's progress and suggests a plan without changing an enrollment or a grade, and splitting a service only with proven justification.

AI: Tool calling and workflows

What will you learn?: Tools with defined contracts, schema validation, permissions, bounded workflows, approval for sensitive operations, evals, and audit trails.
Why?: The assistant performs specific functions safely.
What's the evidence of learning?: It reads a student's progress and suggests a plan, and doesn't change an enrollment or a grade outside the application's permissions and policy.

Java Backend: Distributed systems when there is a need

What will you learn?: Partial failure, consistency, delivery semantics, ordering, idempotent consumers, outbox, sagas, deeper messaging, and splitting a service when clearly justified.
Why?: You understand the consequences of distributing a system.
What's the evidence of learning?: Redelivering an event doesn't repeat its effect, and a failure in part of the journey has clear recovery and tests.

Business, design & delivery: Scaling decisions and trade-offs

What will you learn?: Scale estimates, a cost model, buy versus build, monolith versus services, contracts, and a migration plan.
Why?: Added complexity must pay for itself.
What's the evidence of learning?: You prove a bottleneck or a need for independence, compare solutions, and have a rollback plan.

Communication & professional: Negotiation and mentoring

What will you learn?: Negotiating scope, time, and quality; delegation; mentoring; and resolving disagreement with evidence.
Why?: A senior's impact includes enabling others.
What's the evidence of learning?: A colleague delivers an independent part while you review the risks and the result without doing every detail.

Stage 6 — Staff / Architect and beyond: impact beyond a single team · Steps 19–21

Stage goal: Connect technical direction to platform economics and enable multiple teams. Staff and Architect may be different paths, not necessarily consecutive ranks.

Exit evidence: Initiatives adopted by several teams, lasting measurable results, and knowledge and ownership that continue without depending on you day to day.

19 A shared platform and its economics

Where do we apply this in the platform? Reproducible environments for several teams, and measured cost per center, student, and AI session.

AI: Operating AI at product scale

What will you learn?: Versioned prompts/evals, model selection, routing/fallback, caching, budgets, monitoring, data policies, and reviewing provider changes.
Why?: Quality, cost, and behavior are tracked as usage and models change.
What's the evidence of learning?: A model or prompt change goes through tests, gradual rollout, rollback, and a cost and quality comparison.

Java Backend: Shared platform engineering

What will you learn?: Cloud architecture, IAM/networking, Infrastructure as Code such as Terraform, IaC review, deployment strategies, supply-chain security, and Kubernetes when operationally justified.
Why?: Multiple teams build and operate on reliable foundations.
What's the evidence of learning?: Creating a reproducible environment, testing its isolation and recovery, and measuring its operating cost.

Business, design & delivery: Platform economics

What will you learn?: Cost per tenant, student, and AI session; budgets; quotas; customer support; investment priorities; and vendor risks.
Why?: Growth stays sustainable.
What's the evidence of learning?: A technical decision that improves a measured cost or experience, with its side effects explained.

Communication & professional: Communicating with management and product

What will you learn?: Executive summaries and presenting options in terms of impact, cost, and risk.
Why?: You connect engineering investment to the organization's goals.
What's the evidence of learning?: A non-technical decision maker understands the alternatives and can choose between them.

20 Architecture and strategy across teams

Where do we apply this in the platform? API and event governance across the platform's teams, and shared migrations that don't break consumers.

AI: Enabling teams with AI

What will you learn?: Task and context templates, tool guardrails, evaluating workflows, and quality and rework metrics.
Why?: The benefit extends to the team and can be measured.
What's the evidence of learning?: A pilot that shows delivery time, defects, and rework, then a recommendation based on the results.

Java Backend: Architecture across teams

What will you learn?: API/event governance, compatibility, schema evolution, platform boundaries, migration at scale, and reliability/security standards.
Why?: One team's changes don't break the rest of the platform.
What's the evidence of learning?: A migration shared across teams without unplanned downtime or broken consumers.

Business, design & delivery: Technical strategy and portfolio

What will you learn?: Capability maps, build versus buy, sequencing, technical debt, investment priorities, and tying the technical roadmap to the product.
Why?: You direct several teams' effort toward the organization's most important problems.
What's the evidence of learning?: A strategy that turns into deliverable, measurable initiatives and is revised with evidence.

Communication & professional: Influence without direct authority

What will you learn?: Stakeholder alignment, proposals, managing disagreement, and mentoring technical leaders.
Why?: The scope of the work is larger than one person's authority.
What's the evidence of learning?: Teams adopt a decision, implement it, and keep it going after you step back from the daily details.

21 Deep specialization and growing leaders

Where do we apply this in the platform? A deep specialization that solves recurring problems in the platform, and leaders and teams who carry the direction forward independently.

AI: Choosing opportunities and the limits of automation

What will you learn?: Assessing where AI helps and where rules or traditional search are enough, with an exit strategy from a costly dependency.
Why?: You choose an investment that fits the problem.
What's the evidence of learning?: You accept or reject an AI project with a reviewable comparison.

Java Backend: Deep specialization by direction

What will you learn?: Choosing a field: JVM/performance, distributed systems, security, data, platform, or AI systems.
Why?: You build depth to solve hard, recurring problems.
What's the evidence of learning?: A solution that affects several systems or teams, and reusable knowledge.

Business, design & delivery: Staff / Architect scope

What will you learn?: An ambiguous problem across teams, a target architecture, a transition roadmap, organizational consequences, and measuring long-term impact.
Why?: You expand the organization's ability to build and change.
What's the evidence of learning?: Sustained improvement in delivery, reliability, cost, or product growth across more than one team.

Communication & professional: Growing leaders and continuity

What will you learn?: Coaching, succession, communities of practice, and distributing knowledge and ownership.
Why?: The results continue without permanent dependence on you.
What's the evidence of learning?: Leaders and teams develop the direction and make suitable decisions independently.

Evidence-of-learning checklist

This list is for you, not a certificate. Next to each piece of evidence, write a link or a note that proves it.

Example: enrolling in a course:

Explain — I explain the idea and its limits in my own words. I explain why Enrollment is its own entity, and when a UNIQUE constraint isn't enough on its own.
Change — I apply it to a new requirement. I add a rule that enrollment closes one day before the course starts.
Diagnose — I reproduce a bug and fix it. I reproduce a duplicate enrollment, fix it, and prove the fix with a test.
Prove and justify — I test the behavior and explain my choice. I write tests for success and rejection, and explain why I chose a database constraint.

Step	Explain	Change	Diagnose	Prove and justify
01 Your environment and a clear question	☐	☐	☐	☐
02 Java basics and problem solving	☐	☐	☐	☐
03 Modeling code in Java	☐	☐	☐	☐
04 Developer tools and early testing	☐	☐	☐	☐
05 Databases and data modeling	☐	☐	☐	☐
06 The web and API contracts	☐	☐	☐	☐
07 Spring Boot and data storage	☐	☐	☐	☐
08 Accounts and permissions	☐	☐	☐	☐
09 Testing strategy and quality	☐	☐	☐	☐
10 Operations, deployment, and a first release	☐	☐	☐	☐
11 Concurrency and consistent rules	☐	☐	☐	☐
12 Performance and non-functional requirements	☐	☐	☐	☐
13 Integrations and background jobs	☐	☐	☐	☐
14 A first AI feature in the product	☐	☐	☐	☐
15 A content-grounded assistant	☐	☐	☐	☐
16 Architecture and turning the platform into SaaS	☐	☐	☐	☐
17 Reliability and incident management	☐	☐	☐	☐
18 Distributed systems and scaling decisions	☐	☐	☐	☐
19 A shared platform and its economics	☐	☐	☐	☐
20 Architecture and strategy across teams	☐	☐	☐	☐
21 Deep specialization and growing leaders	☐	☐	☐	☐