It’s time to move from the foundations of Java and Object-Oriented Programming into real-world backend development.

In this course, you won’t just learn Spring Boot features or annotations. You will build a production-style backend application from the ground up, step by step, and learn professional backend development through the process.

The course follows the workflow of a real engineering team—from understanding requirements and creating technical designs, RFCs, and engineering tickets to implementation, testing, code review, deployment, and investigating production issues.

Throughout the course, the same application will continue to evolve. Instead of learning each new concept through isolated examples, you will see where it fits in a real system, why it is needed, and how it is applied in practice.

The goal of this course is not simply to complete a backend project.

The goal is to build the foundation you need as a backend engineer to think about, design, build, and maintain production-quality software.

In this course, we are not going to learn Java or Spring Boot features through a collection of isolated examples. Instead, we will build a real-world backend application and evolve that same application throughout the course.

You are not just a learner here. From this moment on, imagine that you have joined a software engineering team as a new **Backend Engineer**. Your team is about to build a new **Order Management Backend**.

The system will allow customers to browse products, place orders, make payments, view their order history and cancel eligible orders. Administrative users will be able to create and update products, deactivate products, manage inventory and view orders.

But we are not going to start by writing code. Professional software development usually does not begin with "new project, open the IDE, start coding". A more realistic process looks like this:

```mermaid
flowchart LR
    A["Business Problem"] --> B["Requirements"] --> C["Technical Discussion"] --> D["Design"] --> E["Engineering Tasks"]
    E --> F["Implementation"] --> G["Testing"] --> H["Review"] --> I["Deployment"] --> J["Operation"]
```

The purpose of this course is to let you experience that entire process in practice.

## The Project We Are Joining

Imagine that we work for a commerce company. The company already sells products, but now it wants a dedicated backend system for its ordering process, and our team's responsibility is to build that backend.

The initial version will support several core capabilities:

* product management
* inventory management
* order creation
* payment processing
* order history
* order cancellation
* administrative operations

Customer identity will come from the application's authentication mechanism. We are **not** building a separate customer-account management subsystem as part of this project.

As the course progresses, we will implement these capabilities gradually. Keep one important idea in mind:

> **We are not going to build the entire system at once.**

Professional software is usually delivered through small, reviewable, incremental changes. Our project will evolve the same way.

## Your Role

In this project, you are a **Backend Engineer**. That means your job is not limited to writing APIs. A backend engineer may need to:

* understand product requirements
* identify ambiguous requirements and ask clarifying questions
* design technical solutions
* define API contracts
* design database models
* implement business logic
* write tests
* review another engineer's code
* explain technical changes
* investigate production failures
* modify an existing system safely
* document technical decisions

Throughout the course, we will practise different parts of these responsibilities.

## Software Development Is More Than Writing Code

When learning programming, we often work with a simplified model: a problem goes in, we write code, and the code produces output. That model is useful for small programming exercises. Production software is different: there are many important decisions between the problem and the code.

Suppose a Product Manager says:

> A customer should be able to place an order.

That sounds simple. But as backend engineers, we should immediately start asking questions:

* Can an order contain multiple products? Can the same product appear more than once?
* What happens if inventory is insufficient? When should inventory decrease?
* Can a customer cancel an order? Can an unpaid order be cancelled? Can a paid one?
* What happens if payment succeeds but our database update fails?
* How do we calculate the final price? Should it come from the current product price, and what happens if that price changes later?

This is one of the major differences between software engineering and simply writing code. Writing the code is often the most straightforward part. The difficult part is:

> **Understanding exactly which problem needs to be solved and how the system should behave.**

## We Will Not Start With Spring Boot

This is a Java backend development course. Even so, the first few lessons will contain very little Spring Boot code, and that is intentional.

A framework is a tool. Spring Boot gives us capabilities such as HTTP controllers, dependency injection, configuration, database integration, validation and application lifecycle management. But Spring Boot cannot decide whether:

* the requirement has been understood correctly
* a responsibility belongs in the right component
* an API contract is well designed
* a business invariant has been identified
* a transaction is required
* a failure scenario has been handled correctly
* a change is risky
* a production incident has been investigated properly

Learning the framework is important, but knowing a framework and being a backend engineer are not the same thing. Throughout this course, we will develop both: backend engineering thinking and its implementation in Java and Spring Boot.

## Our Engineering Workflow

Throughout the course, we will follow a repeatable engineering workflow. A feature will usually move through a process similar to this:

```mermaid
flowchart TD
    A["Requirement"] --> B["Understand and clarify the problem"]
    B --> C["Technical design"]
    C --> D["RFC / ADR when needed"]
    D --> E["Break work into tickets"]
    E --> F["Implementation and testing"]
    F --> G["Pull request and code review"]
    G --> H["Merge"]
    H --> I["Deploy"]
    I --> J["Observe"]
```

Not every small change needs a full RFC. That is also an important engineering lesson: documentation should not exist to create bureaucracy. Its purpose is to improve thinking and communication where those things are valuable. Later, we will learn when a short engineering ticket is enough, when an ADR is appropriate and when a larger RFC is worth writing.

## RFCs and ADRs

You will see the term **RFC** throughout this course. RFC commonly stands for **Request for Comments**. In a software engineering team, an RFC can be a document in which an engineer explains a technical problem and proposes a solution so that other engineers can review it before implementation. An RFC might contain sections such as Problem, Context, Goals, Non-Goals, Proposed Design, Alternatives, Risks and Rollout Plan.

Not every company uses the same format. Some teams call these documents design documents, technical proposals or engineering proposals. The name is less important than the purpose:

> **Think about and discuss important technical decisions in a structured way before hiding those decisions inside code.**

We will write RFCs for our Order Management Backend when the problem justifies one.

Another term we will use is **ADR — Architecture Decision Record**. An ADR records a specific technical decision and the reasoning behind it, for example why we are using PostgreSQL, why we are using database migrations or why we chose a particular API error format.

An RFC may describe a larger technical proposal; an ADR usually focuses on preserving one important decision and its reasoning. Months later, when another engineer joins the project, they should not have to reverse-engineer the reason behind every architectural choice by reading code. They should be able to read the relevant ADR and understand the context.

## Engineering Tickets

After designing a solution, we will break the work into smaller engineering tasks:

```text
BACKEND-101 Bootstrap Order Management Backend
BACKEND-102 Create Product domain model
BACKEND-103 Add Product persistence
BACKEND-104 Expose Product API
BACKEND-105 Implement Order creation
```

A useful ticket should not simply say "Build orders." It should provide enough context to understand the expected behaviour. Later, we will work in more detail with user stories, acceptance criteria and the Definition of Done.

Tickets are not merely project-management tracking tools. A well-written ticket creates a useful boundary around engineering work. A ticket that says "Implement ordering system" has a scope so large that an engineer may not even know where to start. Compare it with:

```markdown
BACKEND-121

Create an order for an authenticated customer.

Acceptance Criteria:

- Order must contain at least one item.
- Every referenced product must exist.
- Requested quantity must be available.
- Order total must be calculated from server-side product prices.
- Invalid requests must return an appropriate API error.
```

The problem is now much clearer. Smaller engineering work is not only easier to manage. It also makes review, testing, rollback and parallel work easier, keeps risk smaller and makes progress easier to understand.

## Pull Requests Are Communication

Writing the code does not mean the work is finished. In a professional engineering team, a change usually goes through review: we create a **Pull Request**, commonly called a **PR**. A useful PR description might look like this:

```markdown
## What

Adds order cancellation support.

## Why

Customers need to cancel unpaid orders.

## Changes

- Added cancellation domain logic
- Restores consumed inventory
- Added cancellation API
- Added integration tests

## Testing

- Unit tests
- API integration tests

## Risks

Inventory restoration happens inside the order transaction.
```

A PR is not just a container for code. It is communication with the reviewer, who should be able to understand quickly what changed, why it changed, how it was tested and where the risks are. This is an extremely important skill in a real engineering career.

## Production Changes Everything

Running an application successfully on a local machine is not the end of software development. Production systems introduce additional questions:

* How will we know if the service is healthy?
* What happens when the database is unavailable, or when an external payment API times out?
* How do we find a failed request?
* What happens during deployment? Can a database migration break existing application instances?
* Can the same payment request be processed twice?
* What happens if two customers try to buy the final item simultaneously?

Questions like these are what make backend engineering interesting. We do not need to know every answer at the beginning of the course. In fact, we should not try to solve every possible future problem immediately. As the system evolves, new problems will naturally appear, and then we will learn and apply the appropriate solution.

## We Will Make Mistakes

We will not begin the course with a perfectly designed system, and real software rarely begins with perfect architecture either. We will make decisions. Later, new requirements will arrive, some assumptions may turn out to be wrong and some designs may need to change. We will even simulate a production incident.

That is not a failure of the course. That is software development: real systems evolve over time. A strong engineer's skill is not simply the ability to write the correct code on the first attempt. It is also:

> **The ability to change an existing system safely.**

## Our First Version Will Be a Modular Application

Our Order Management Backend will begin as a single backend application. Conceptually:

```text
Order Management Backend
├── Products
├── Inventory
├── Orders
└── Payments
```

Customer identity is supplied by the authentication system and used by application workflows, but we are not creating a separate Customer management capability.

At this stage of the course, we will not split the application into unnecessary microservices. Our current goal is to learn how to build production-quality backend software. Microservices, Kafka, distributed transactions, distributed caching and service meshes become useful only when there is a real problem that requires them.

Architecture complexity is not an achievement by itself. A system that satisfies its requirements with a simpler architecture is usually a better starting point.

## What We Will Build Toward

By the end of the course, our application will be much more than a collection of CRUD endpoints. We will build a backend with HTTP APIs, business logic, domain models, validation, PostgreSQL persistence, database migrations, transactions, authentication and authorization, external service integration, tests, logging, metrics, health checks, Docker, CI and deployment practices.

But we will not learn these as an arbitrary checklist. Each capability will appear because the project creates a reason for it:

* We will learn **PostgreSQL** because the application needs durable data.
* We will learn **transactions** because Order creation changes multiple pieces of database state that must remain atomic.
* We will learn **authentication and authorization** because one Customer must not be able to access another Customer's Orders.
* We will learn **timeouts and retries** because an external payment provider will not always respond perfectly.
* We will learn **observability** because when something fails in production, engineers need to understand what happened inside the system.

This distinction is important:

> **Problem first. Technology second.**

## Your Engineering Repository

As the course progresses, our repository may evolve into something like:

```text
order-management/
├── src/
│   ├── main/
│   └── test/
├── docs/
│   ├── rfcs/
│   ├── adr/
│   └── incidents/
├── Dockerfile
├── compose.yaml
└── README.md
```

`src/` contains application code, `docs/rfcs/` larger technical proposals, `docs/adr/` architecture decisions, and `docs/incidents/` will later contain production incident reviews. Engineering context becomes part of the repository alongside the code.

## A Backend Engineer Thinks in Behaviour

Throughout this course, we will develop one important habit:

> Do not immediately think about implementation when you see a feature request.

Think about behaviour first. Suppose the requirement says "Customer can cancel an order." Do not immediately write `order.setStatus(OrderStatus.CANCELLED);`. First ask:

* Which orders can be cancelled? Can a paid order be cancelled?
* Should inventory be restored?
* Can the same order be cancelled twice?
* Who is allowed to cancel the order?
* What response should the API return?
* Do we need to notify another system?

Only after understanding the behaviour should we design the implementation. The order matters: behaviour first, then design, then code — not code first and trying to figure out the behaviour later.

## Think Like You Just Joined the Team

At this point, we still do not have a complete set of requirements. All we know is the high-level context:

> The company wants to build an Order Management Backend.

An inexperienced developer might already open an IDE and create an `OrderController`. We are not going to do that. Our next responsibility is to understand the business requirement. We need to discover:

* who will use the system
* what they should be able to do
* which behaviours are mandatory
* which behaviours are outside this version
* which constraints exist
* how success will be defined

Without that information, we might write code quickly and still build the wrong system.

## Engineering Principle

> **The job is not to write code. The job is to solve the right problem with software.**

Code is an important part of that job. But before code comes understanding, and after production comes ownership. A backend engineer participates in the entire lifecycle.

## Summary

* We join a team building the **Order Management Backend** and evolve that one application through the whole course.
* A backend engineer's work goes from understanding requirements and asking questions through design, implementation, testing and review to operating the system in production.
* Spring Boot is a tool; it cannot decide whether we understood the requirement or designed the behaviour correctly.
* RFCs propose larger technical changes for review; ADRs preserve one decision and its reasoning; tickets give work a clear, reviewable boundary.
* A pull request is communication: what changed, why, how it was tested and where the risks are.
* We start with a simple modular application and add technology only when a real problem requires it: problem first, technology second.
* Behaviour comes before design, and design before code.

In the next lesson, our team receives the actual product requirement for the Order Management Backend. It intentionally begins at a high level, and we will read it like engineers: separating what is explicitly required from what we are assuming, what is ambiguous, what needs clarification and what should not be built yet.


Welcome to the Engineering Team

Understanding the Product Requirement

Functional vs Non-Functional Requirements

User Stories and Acceptance Criteria

Understanding the Existing Engineering Context

Definition of Done

Creating Our Initial Engineering Backlog

Prioritizing and Refining the Backlog

Joining the Backend Team

From Requirements to Technical Design

Identifying Domain Entities

Defining System Responsibilities

Designing the Initial Architecture

Writing Our First RFC

Architecture Decision Records

Reviewing and Revising a Technical Design

Designing the System

Creating a Spring Boot Application

Understanding Spring Boot Project Structure

Dependency Injection

Beans and the Application Context

Configuration and Application Properties

Environment-Specific Configuration

Structuring a Backend Codebase

Running the Application Locally

Building the Spring Boot Application

Turning Business Concepts into Domain Models

Entities, Value Objects, and DTOs

Separating Domain Logic from Transport Logic

Modeling Product

Modeling Customer

Modeling Orders and Order Items

Modeling Order State

Avoiding Anemic Domain Models

Domain Modeling

HTTP Through a Backend Engineer's Eyes

Designing Resources and Endpoints

Controllers in Spring Boot

Request and Response Models

HTTP Status Codes

Request Validation

Consistent API Error Responses

Pagination and Filtering

API Versioning

Documenting APIs with OpenAPI

Generating OpenAPI with springdoc-openapi

Building REST APIs

Why Our Application Needs Persistence

Relational Database Thinking

Designing the Initial Schema

Primary Keys and Foreign Keys

Spring Data JPA

Entity Mapping

Relationships

Repositories

Database Migrations with Flyway

Indexes and Query Performance

Pagination at the Database Layer

Avoiding Common JPA Problems

Persistence with PostgreSQL

UseCase Responsibilities

Implementing Product Creation

Implementing Product Updates and Deactivation

Implementing Product Browsing

Implementing Inventory Management

Implementing Order Creation

Calculating Order Totals

Checking and Consuming Inventory Safely

Database Transactions

Rollback and Failure Scenarios

Order State Transitions

Order Cancellation

Business Errors vs System Errors

Implementing Business Workflows

Authentication vs Authorization

Integrating Authenticated User Identity

Enforce Customer Resource Ownership

Enforce Administrator Permissions

Authentication and Authorization

Defining the Payment Integration Boundary

Implementing the Payment Provider Client

Handling Timeouts and External Failures

Retry Safety and Idempotency

External Side Effects vs Database Transactions

Payment Consistency and Failure Recovery

Handling Pay vs Cancel Concurrency

Persisting Payment Attempts

Implementing the Order Payment Workflow

Exposing the Order Payment API

Working with External Services

Building a Testing Strategy

Testing Domain Logic

Testing UseCases with Test Doubles

Repository Integration Testing with PostgreSQL

Using Testcontainers

Testing Transactions and Rollback

API Integration Testing

Testing Authentication and Authorization

Testing External Service Integrations

Testing Concurrency and Race Conditions

Choosing What to Mock

Building a Maintainable Test Suite

Backend Testing in Practice

Structured Application Logging

Request Correlation

Application Health Checks

Application Metrics

Implementing Metrics with Micrometer and Prometheus

Production Observability

Containerizing the Application

Creating a CI Build and Test Pipeline

Runtime Environments and Deployment Configuration

Running Database Migrations During Deployment

Release, Rollout, and Rollback Strategies

Shipping Software

The Production Incident

Investigating With Production Signals

Reconstructing the Failure Timeline and Finding the Root Cause

Designing Request-Level Idempotency for Create Order

Implementing the Idempotency Workflow

Handling Concurrent Idempotent Retries

Adding the Complete Regression Test Suite

Writing the Incident Review

Handling Production Incident

Understanding the Production Change Request

Assessing the Impact on the Existing System

Investigating the Payment Provider Refund Contract

Designing Refund State and the Refund Workflow

Designing the Refund API and Persistence Model

Implementing the Refund Domain and Persistence Model

Extending the Payment Provider Boundary for Refunds

Implementing the Three-Phase Refund Workflow

Implementing Refund Reconciliation

Exposing and Securing the Refund API

Testing the Refund Workflow End to End

Rolling Out the Refund Change Safely

Course Wrap-Up

Production Change Request

Build a production-style Java backend with Spring Boot while learning real-world engineering practices, from requirements and RFCs to testing, deployment, and production incidents.

Backend Development with Java & Spring Boot

Checking lesson access...