Introduction to Microservices Architecture

Course: Advanced Java Training

Topic: Introduction to Microservices Architecture

Course Link: Advanced Java Training Course

Demo Link: Register for a Course Demo

Website: JustAcademy

1. Introduction to Microservices Architecture

Microservices architecture is a software architectural style in which an application is developed as a collection of small, independent services. Each service is responsible for a specific business capability and communicates with other services through well-defined interfaces such as REST APIs, gRPC, or messaging systems.

Unlike traditional monolithic applications, where most functionality is packaged and deployed as a single unit, microservices divide an application into smaller services that can be developed, tested, deployed, and scaled independently.

Microservices architecture is widely used in enterprise applications, e-commerce platforms, banking systems, healthcare applications, streaming platforms, and cloud-native software. It is particularly useful when different parts of an application have different scaling requirements or need to be released independently.

Example

Consider an online shopping application. It may contain customer registration, product catalog, shopping cart, order processing, payment, and notification functionality. In a microservices architecture, these capabilities can be implemented as separate services that communicate with each other to complete a customer purchase.

2. Learning Objectives

• Understand the meaning and purpose of microservices architecture.
• Identify the main characteristics of microservices.
• Understand the differences between monolithic and microservices architectures.
• Learn how services communicate with one another.
• Understand service boundaries and business capabilities.
• Explore the role of Spring Boot in building microservices.
• Learn about API gateways, service discovery, and centralized configuration.
• Understand distributed data management, security, and fault tolerance.
• Explore the benefits, challenges, and common design patterns of microservices.

3. What Is a Microservice?

A microservice is a small, independently deployable software service that performs a clearly defined business function. It owns its business logic and typically manages its data through a private database or storage boundary.

A microservice exposes a contract that other services can use without needing to understand its internal implementation. This separation makes it possible to modify or replace a service while minimizing the impact on other parts of the application.

Examples of Microservices

4. What Is Monolithic Architecture?

Monolithic architecture is a traditional software architecture in which multiple application functions are developed and deployed as one integrated application. The application may contain several logical modules, but they are generally packaged and released together.

For example, an e-commerce application may contain user management, product management, ordering, and payment modules within a single deployable application.

Characteristics of Monolithic Applications

• Most application functionality is packaged into a single deployment unit.
• Modules may share application memory and database structures.
• Testing and deployment are often performed for the complete application.
• Scaling one feature may require scaling the entire application.
• A large codebase can become difficult to maintain when module boundaries are unclear.

Monolithic architecture is not necessarily a poor design. For smaller applications, prototypes, and systems with straightforward requirements, a well-structured monolith can be simpler and more cost-effective than a distributed microservices system.

5. Monolithic Architecture vs. Microservices Architecture

6. Key Characteristics of Microservices Architecture

6.1 Independent Deployment

Each microservice can be built and released independently. A change to the notification service, for example, does not necessarily require redeploying the product catalog service.

6.2 Loose Coupling

Services interact through clearly defined APIs or events instead of depending on one another's internal classes, database tables, or implementation details.

6.3 Business-Capability Focus

Each service represents a business responsibility, such as order processing, inventory management, or payment coordination.

6.4 Independent Scaling

Services can be scaled according to their workload. If product searches receive heavy traffic, additional product service instances can be deployed without automatically increasing the number of payment service instances.

6.5 Decentralized Data Ownership

Each service controls its own data and exposes appropriate operations to other services. Other services should not directly modify its private database tables.

6.6 Fault Isolation

Well-designed services can limit the impact of failures. Timeouts, circuit breakers, bounded retries, and graceful degradation help prevent one unavailable dependency from causing widespread failure.

6.7 Automation

Automated builds, testing, containerization, deployment, and monitoring make it easier to manage multiple independently released services.

7. Main Components of Microservices Architecture

7.1 Client Application

The client may be a web application, mobile application, desktop application, or another system that sends requests to the backend.

7.2 API Gateway

An API gateway provides a common entry point for client requests. It can route requests, enforce policies, handle authentication integration, apply rate limits, and aggregate results where appropriate.

7.3 Individual Microservices

Each microservice implements a particular business capability. Examples include user, product, order, inventory, and payment services.

7.4 Service Discovery

Service discovery helps services locate available instances of other services. Depending on the deployment environment, discovery may use a registry, DNS, or platform-provided networking.

7.5 Database or Data Store

Each service should control its own data boundary. Different services may use relational databases, document databases, caches, or other storage systems according to their requirements.

7.6 Message Broker

A message broker supports asynchronous communication between services. Examples include Apache Kafka and RabbitMQ.

7.7 Configuration Management

Configuration management separates environment-specific settings from application code and provides controlled ways to manage service configuration.

7.8 Monitoring and Logging

Centralized logs, metrics, traces, and health checks help developers understand the behavior of distributed services and diagnose failures.

8. High-Level Microservices Architecture Diagram

                  Web / Mobile Client
                          |
                          v
                     API Gateway
                          |
           +--------------+--------------+
           |              |              |
           v              v              v
      User Service   Product Service   Order Service
           |              |              |
           v              v              v
       User DB         Product DB       Order DB
                                          |
                                          v
                                    Payment Service
                                          |
                                          v
                                      Payment DB

           Order Events / Message Broker
                          |
                          v
                  Notification Service
                          |
                          v
                   Email / SMS Provider

      Monitoring, Logging, Security and Deployment
                 support all services

This diagram illustrates a conceptual architecture. Actual communication paths depend on the business workflow. For example, the order service may call a payment service synchronously or publish an event for asynchronous processing. The correct choice depends on consistency, latency, reliability, and user-experience requirements.

9. Understanding Service Boundaries

Service boundaries determine which business logic and data belong to each microservice. Choosing these boundaries is one of the most important parts of microservices design.

Services should be organized around cohesive business capabilities rather than arbitrary technical layers. For example, creating separate services for every database table or every small utility method can produce excessive network communication and operational overhead.

Example: E-Commerce Service Boundaries

• User Service: Account profiles and customer information.
• Catalog Service: Product descriptions and categories.
• Inventory Service: Stock availability and inventory reservations.
• Order Service: Order creation, status, and lifecycle.
• Payment Service: Payment requests, transaction status, and payment-provider integration.
• Notification Service: Communication with customers about important events.

Domain-Driven Design (DDD) provides concepts such as bounded contexts that help identify appropriate service boundaries. A bounded context represents a boundary within which a particular domain model and its terminology are consistently defined.

10. How Microservices Communicate

Microservices communicate through synchronous requests, asynchronous messages, or a combination of both. Communication should use stable contracts and avoid exposing internal implementation details.

10.1 Synchronous Communication

In synchronous communication, a service sends a request and waits for a response. HTTP-based REST APIs and gRPC are common approaches.

Example: The order service calls the inventory service to check stock availability before proceeding with an order.

Order Service
      |
      | HTTP Request
      v
Inventory Service
      |
      | HTTP Response
      v
Order Service

Advantages:

• Simple request-response model.
• Immediate response when the dependent service is available.
• Useful for operations that need a result before continuing.

Challenges:

• The caller depends on the availability and response time of the downstream service.
• Network timeouts and transient failures must be handled.
• Long chains of synchronous requests can increase latency.

10.2 Asynchronous Communication

In asynchronous communication, a service publishes a message or event without requiring the consumer to process it immediately. A message broker may store and deliver messages to interested consumers.

Example: After an order is created, the order service publishes an OrderCreated event. The notification service consumes the event and sends a confirmation message.

Order Service
      |
      | Publish OrderCreated
      v
Message Broker
      |
      | Consume Event
      v
Notification Service

Advantages:

• Reduces direct runtime dependencies between producers and consumers.
• Allows consumers to process messages independently.
• Supports event-driven workflows and buffering during temporary load spikes.

Challenges:

• Processing may be delayed.
• Duplicate delivery and message ordering need consideration.
• Eventual consistency and asynchronous error handling require careful design.

11. Introduction to Spring Boot for Microservices

Spring Boot is a Java framework that simplifies the creation of standalone, production-oriented applications. It is commonly used to build microservices because it provides dependency management, auto-configuration, embedded servers, and integration with the wider Spring ecosystem.

Useful Spring Technologies

Not every microservices application needs all these technologies. Select libraries and infrastructure according to the application's actual requirements and the versions supported by the project.

12. Creating a Simple Microservice Using Spring Boot

Let's create a basic Product Service that exposes product information through a REST API. This example introduces the structure of a service without adding unnecessary infrastructure.

Step 1: Create a Spring Boot Project

Create a project using Spring Initializr or your preferred Java IDE. Select a compatible Java version and add the Spring Web dependency.

Suggested project details:

• Project: Maven
• Language: Java
• Framework: Spring Boot
• Dependency: Spring Web
• Service Name: product-service

Step 2: Create a Product Model

package com.example.product;

public class Product {

    private Long id;
    private String name;
    private double price;

    public Product() {
    }

    public Product(Long id, String name, double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }
}

This model represents a product with an identifier, name, and price. For a production application, monetary values are generally better represented using BigDecimal rather than double.

Step 3: Create a REST Controller

package com.example.product;

import org.springframework.web.bind.annotation.*;
import java.util.List;

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final List<Product> products = List.of(
        new Product(1L, "Laptop", 65000.00),
        new Product(2L, "Keyboard", 1500.00),
        new Product(3L, "Mouse", 800.00)
    );

    @GetMapping
    public List<Product> getAllProducts() {
        return products;
    }

    @GetMapping("/{id}")
    public Product getProductById(@PathVariable Long id) {
        return products.stream()
            .filter(product -> product.getId().equals(id))
            .findFirst()
            .orElseThrow(() ->
                new ProductNotFoundException(
                    "Product not found: " + id
                )
            );
    }
}

Step 4: Create a Custom Exception

package com.example.product;

public class ProductNotFoundException
        extends RuntimeException {

    public ProductNotFoundException(String message) {
        super(message);
    }
}

For a complete API, add an exception handler that maps ProductNotFoundException to HTTP 404 Not Found. This keeps error responses meaningful and avoids exposing internal exceptions.

Step 5: Run and Test the Service

Start the Spring Boot application and send a GET request to the following endpoint:

GET http://localhost:8080/api/products

Example response:

[
  {
    "id": 1,
    "name": "Laptop",
    "price": 65000.0
  },
  {
    "id": 2,
    "name": "Keyboard",
    "price": 1500.0
  },
  {
    "id": 3,
    "name": "Mouse",
    "price": 800.0
  }
]

To retrieve one product, use:

GET http://localhost:8080/api/products/1

This example uses an in-memory list, so its data is temporary and disappears when the application restarts. A real product service would generally use a repository and persistent database.

13. Building Multiple Microservices

A microservices application usually consists of multiple separately runnable services. For example, a product service may run on port 8081 and an order service on port 8082.

These port numbers are illustrative. Each service should have its own application configuration, deployment lifecycle, and clear responsibility. In production, service addresses are normally managed through platform networking, service discovery, or environment configuration rather than hardcoded localhost URLs.

14. API Gateway in Microservices

An API gateway acts as a single entry point between client applications and backend microservices. It routes incoming requests to the appropriate service and can centralize certain cross-cutting concerns.

Common Responsibilities

• Route requests to backend services.
• Apply authentication and authorization policies where appropriate.
• Enforce rate limits and traffic policies.
• Handle TLS termination and request filtering.
• Aggregate responses when a client needs data from multiple services.
• Provide gateway-level logging and metrics.

Example Request Flow

Mobile Application
        |
        v
    API Gateway
        |
        +------> Product Service
        |
        +------> Order Service
        |
        +------> User Service

The gateway simplifies client connectivity, but it should not become a central place for all business logic. Services must still enforce their own authorization and business invariants where necessary.

15. Service Discovery

In a distributed environment, service instances may start, stop, scale, or move between machines. Service discovery provides a way to locate healthy service instances without requiring every client to maintain a fixed address.

Types of Service Discovery

• Client-side discovery: A client queries a registry and chooses an available service instance.
• Server-side discovery: A gateway, load balancer, or platform routes the request to a suitable service instance.

For example, a deployment platform may expose the product service through an internal DNS name. Other services can use that stable name rather than tracking individual container addresses.

Service discovery is particularly helpful when the number of instances changes dynamically. However, it does not replace health checks, load balancing, or resilience mechanisms.

16. Centralized Configuration Management

Microservices need configuration for database connections, service endpoints, feature flags, timeouts, and other environment-specific settings. Keeping these values embedded in source code makes deployment and maintenance more difficult.

Configuration management allows settings to be maintained separately from application code and supplied for development, testing, staging, and production environments.

Benefits

• Separates configuration from business logic.
• Reduces hardcoded environment-specific values.
• Supports controlled changes across deployments.
• Helps standardize configuration practices across teams.

Sensitive information such as database passwords, API keys, and signing keys should be stored in an appropriate secrets-management system. A configuration server alone should not be treated as a secure secrets vault.

17. Database Per Service Pattern

The database-per-service pattern means that each microservice owns and controls its data. Other services access that information through APIs or events rather than directly querying or modifying the owner's private database.

Example

• The product service owns product descriptions and catalog data.
• The order service owns order records and order status.
• The payment service owns payment transaction records.
• The inventory service owns stock levels and reservations.

Advantages

• Services can evolve their schemas independently.
• Database access remains aligned with service responsibilities.
• Different storage technologies can be selected where justified.
• Teams can manage persistence changes within their service boundary.

Challenges

• Combining data across services requires APIs, events, or data projections.
• Distributed transactions become more complicated.
• Data duplication may be necessary for efficient queries.
• Cross-service consistency must be designed deliberately.

Separate ownership does not necessarily require a separate physical database server for every service. Services may share database infrastructure while maintaining distinct ownership and access boundaries.

18. Distributed Transactions and Eventual Consistency

In a monolithic application, a single database transaction may update several related tables. In microservices, a business workflow may involve multiple services, each with its own data store. A single local transaction generally cannot atomically cover all these stores.

One approach is to use a saga: a sequence of local transactions coordinated through commands or events. If a step fails, compensating actions can help reverse earlier business effects where reversal is possible.

Example: Order Processing Saga

1. The order service creates a pending order.
2. The inventory service reserves stock.
3. The payment service attempts payment authorization.
4. The order service marks the order confirmed after the required steps succeed.
5. If a later step fails, the workflow may release reserved stock or cancel the pending order as appropriate.

Real payment operations need careful treatment because a charge cannot always be undone in the same way as a database update. Idempotency keys, reconciliation, retries, and explicit transaction states are important for reliable workflows.

19. Resilience and Fault Tolerance

Microservices rely on network communication, which introduces failures such as timeouts, dropped connections, slow responses, and unavailable dependencies. Resilience patterns help a system respond safely when these failures occur.

Retries must be designed carefully. Retrying a non-idempotent operation, such as charging a customer, can produce duplicate effects unless idempotency and transaction handling are implemented correctly.

20. Security in Microservices Architecture

Security is essential because microservices expose APIs and exchange information over a network. Each service must protect its data and operations while maintaining secure communication with other services.

Important Security Practices

• Use HTTPS/TLS to protect network communication.
• Authenticate users and services using appropriate identity mechanisms.
• Enforce authorization for individual resources and operations.
• Validate request data and reject malformed input.
• Store credentials and secrets securely.
• Use least-privilege permissions for services and database accounts.
• Apply rate limiting and abuse protection where needed.
• Keep dependencies patched and scan application images for vulnerabilities.
• Audit sensitive operations without logging confidential values.
• Use network policies and controlled service-to-service access.

Authentication at the gateway can reduce repeated work, but it should not be the only security boundary. Individual services should validate the identity and permissions relevant to the operations they perform.

21. Monitoring, Logging, and Distributed Tracing

In a monolithic application, a single log stream may provide a relatively clear view of a request. In microservices, a single user request can travel through many services. Effective observability is necessary to identify where failures, delays, and resource problems occur.

21.1 Centralized Logging

Logs from different services can be collected in a central platform. Structured logs should include useful fields such as timestamp, service name, severity, request identifier, and trace identifier where available.

21.2 Metrics

Metrics provide numerical measurements such as request count, error rate, response latency, CPU usage, memory consumption, and queue depth.

21.3 Distributed Tracing

Distributed tracing follows a request across multiple services by recording trace and span information. It helps identify which downstream call contributes to high latency or failure.

21.4 Health Checks

Health checks help orchestration and monitoring systems understand whether a service is running and whether it is ready to accept traffic. Liveness and readiness checks should have clearly defined meanings.

22. Containerization and Deployment

Containers package an application and its runtime dependencies into a portable unit. They are commonly used to deploy microservices consistently across development, testing, and production environments.

Common Deployment Technologies

• Docker: Builds and runs containers.
• Kubernetes: Orchestrates containerized workloads, scaling, networking, and recovery.
• CI/CD pipelines: Automate build, test, security checks, and deployment.
• Container registries: Store versioned container images.
• Infrastructure as Code: Defines infrastructure through version-controlled configuration.

Containerization is common but not mandatory for microservices. Services can also run on virtual machines, managed application platforms, or other suitable hosting environments.

23. Advantages of Microservices Architecture

• Independent deployment: Teams can release individual services without rebuilding the entire application.
• Selective scaling: High-demand services can receive additional resources independently.
• Team autonomy: Teams can own specific business capabilities and their operational lifecycle.
• Technology flexibility: Different services can use suitable technologies when the benefits justify the complexity.
• Fault isolation: Properly designed boundaries and resilience mechanisms can limit failures.
• Maintainability: Small, cohesive services can be easier to understand than a very large, tightly coupled codebase.
• Continuous delivery: Independent pipelines can support smaller, more frequent releases.
• Incremental modernization: Existing applications can be decomposed gradually when there is a clear business reason.

24. Disadvantages and Challenges of Microservices

• Operational complexity: Many services require more deployment, monitoring, and infrastructure management.
• Network failures: Communication can fail even when the calling code is correct.
• Data consistency: Workflows spanning multiple databases require careful coordination.
• Debugging complexity: A single failure may involve multiple services and asynchronous events.
• Testing complexity: Integration and end-to-end tests must cover service contracts and distributed workflows.
• Security overhead: More service boundaries create more network paths and access policies to protect.
• Infrastructure costs: Additional runtime resources, observability platforms, and deployment tools may increase cost.
• Versioning challenges: Service contracts must remain compatible while different services are deployed at different times.

Microservices should not be selected solely because they are popular. Their benefits are most valuable when the organization has a real need for independent scaling, deployment, ownership, or domain separation and can support the operational complexity.

25. Common Microservices Design Patterns

26. Best Practices for Designing Microservices

• Design services around cohesive business capabilities.
• Keep service boundaries clear and avoid excessive fragmentation.
• Define stable, documented API and event contracts.
• Avoid sharing private database tables between services.
• Use synchronous calls only when a direct response is necessary.
• Use asynchronous messaging for workflows that benefit from decoupling.
• Set timeouts and bounded retries for network calls.
• Design critical operations for safe retry behavior and idempotency.
• Implement centralized observability with trace correlation.
• Automate testing, security scanning, and deployments.
• Use backward-compatible contract changes where possible.
• Keep secrets outside source code and ordinary configuration files.
• Measure system complexity and cost before splitting additional services.
• Consider starting with a modular monolith when requirements do not justify distributed deployment.

27. Practical Project: E-Commerce Microservices System

Project Objective: Design a basic e-commerce backend using Spring Boot microservices to understand service boundaries, REST communication, data ownership, and distributed workflows.

Project Requirements

• Create a Product Service to manage products.
• Create a User Service to manage customer profiles.
• Create an Order Service to create and track orders.
• Create an Inventory Service to check and reserve stock.
• Create a Notification Service to process order events.
• Use REST APIs for operations requiring immediate responses.
• Use a message broker for asynchronous notification processing.
• Apply request validation and standardized error responses.
• Add authentication and authorization for protected endpoints.
• Include logging, health checks, and automated tests.

Suggested Implementation Plan

1. Define the business requirements and responsibilities of each service.
2. Create separate Spring Boot projects for the required services.
3. Implement product and user REST APIs.
4. Implement order creation and inventory checks.
5. Define an event contract for order creation.
6. Connect the notification service to the message broker.
7. Add timeout, retry, and error-handling policies.
8. Test successful orders, unavailable stock, and downstream failures.
9. Containerize the services if required.
10. Document the architecture, API endpoints, and deployment steps.

Expected Learning Outcomes

• Ability to divide an application into business-focused services.
• Understanding of REST-based service communication.
• Experience with asynchronous event processing.
• Knowledge of service data ownership and failure handling.
• Practical exposure to Spring Boot microservices development.

28. Interview Questions and Answers

Q1. What is microservices architecture?

Answer: It is an architectural style in which an application is divided into small, loosely coupled services that implement specific business capabilities and can be deployed independently.

Q2. What is the difference between monolithic and microservices architecture?

Answer: A monolithic application is generally deployed as one unit, whereas a microservices application consists of multiple independently deployable services that communicate through network interfaces or messaging.

Q3. What is a microservice?

Answer: A microservice is an independently managed service that owns a well-defined business responsibility and exposes a contract for interacting with other services.

Q4. Why is Spring Boot used for microservices?

Answer: Spring Boot simplifies standalone Java application development through auto-configuration, embedded servers, dependency management, and integration with Spring libraries.

Q5. What is an API gateway?

Answer: An API gateway is an entry point that routes client requests to backend services and may provide cross-cutting functions such as rate limiting, authentication integration, and request filtering.

Q6. What is service discovery?

Answer: Service discovery allows services or infrastructure components to locate available service instances without relying on manually maintained instance addresses.

Q7. What is the database-per-service pattern?

Answer: It is a design approach in which each service controls its own data and other services interact with that data through supported interfaces or events.

Q8. What is the difference between synchronous and asynchronous communication?

Answer: Synchronous communication waits for a response to a request. Asynchronous communication allows a message or event to be processed later without requiring the producer to wait for the consumer's result.

Q9. What is a circuit breaker?

Answer: A circuit breaker temporarily prevents calls to a dependency that is repeatedly failing, reducing unnecessary requests and helping protect the rest of the system.

Q10. What is eventual consistency?

Answer: Eventual consistency means that different data representations may temporarily disagree but are expected to converge when updates and processing complete, assuming the system continues to operate correctly.

Q11. What is a saga pattern?

Answer: A saga coordinates a distributed business workflow through a sequence of local transactions and, where appropriate, compensating actions for failures.

Q12. How do microservices handle failures?

Answer: They use timeouts, bounded retries, circuit breakers, bulkheads, idempotency, monitoring, and appropriate fallback or compensation strategies.

Q13. What is distributed tracing?

Answer: Distributed tracing records how a request moves across services, making it easier to identify latency, dependency failures, and bottlenecks.

Q14. Are microservices always better than monolithic applications?

Answer: No. Microservices introduce distributed-system and operational complexity. A modular monolith may be a better choice for applications that do not need independent deployment or scaling.

Q15. How can a monolithic application be migrated to microservices?

Answer: Identify well-defined business capabilities, establish service boundaries, extract one capability at a time, route traffic appropriately, and validate data ownership and operational readiness. The Strangler Fig approach can support gradual migration.

29. Quick Revision Checklist

• Understand the definition and purpose of microservices architecture.
• Know the differences between monolithic and microservices designs.
• Identify business capabilities and service boundaries.
• Understand REST APIs, gRPC, and asynchronous messaging.
• Learn the roles of API gateways and service discovery.
• Understand database-per-service and eventual consistency.
• Know the basics of Spring Boot REST services.
• Recognize resilience patterns such as timeouts and circuit breakers.
• Understand authentication, authorization, and secrets management.
• Learn centralized logging, metrics, tracing, and health checks.
• Understand the benefits and operational costs of microservices.
• Know when a monolithic or modular monolithic application is more appropriate.

30. Conclusion

Microservices architecture enables applications to be organized into independent, business-focused services that communicate through APIs or asynchronous messaging. It can improve independent deployment, selective scaling, team ownership, and fault isolation when services have clear boundaries and are supported by suitable infrastructure.

However, microservices also introduce challenges involving network communication, data consistency, security, observability, and deployment operations. Successful implementation requires careful service design, automated testing, resilient communication, and clear data ownership.

For learners interested in expanding their Java development skills, explore the Advanced Java Training course at JustAcademy and register for a course demo.

You can also visit the JustAcademy website for additional learning resources.