Monolith to Microservice: Extracting a Spring Boot Service

1. The Migration Strategy: From Monolith to Microservices

A "big bang" rewrite, where development on the existing system halts in favor of building a new one from scratch, is fraught with risk. A more robust and widely adopted approach is incremental migration. Let's quickly review the core strategy.

The key takeaway is to migrate one piece at a time. This allows the monolith to remain operational while new services are gradually carved out and deployed. This process is often guided by the Strangler Fig Pattern.

The Strangler Fig Pattern, named after a type of vine that grows around a host tree and eventually replaces it, is a powerful architectural pattern for incremental refactoring.

The following video section and a brief reading from a handbook will provide a solid definition of this crucial pattern.

Our goal for today is to take the first practical step in this pattern: extracting a module into a new, independent service.

2. The Practice: Extracting Microservices from a Monolith

We will now walk through the process of taking a hypothetical monolithic application containing Company, Job, and Review functionalities and extracting each into its own Spring Boot microservice.

The following video is a comprehensive, step-by-step guide that mirrors exactly what we need to learn. We will go through it section by section, starting with the Job service.

Key Refactoring Steps for the Job Microservice

As you saw in the video, the process involves more than just copying code. The most critical step is decoupling.

1. New Project Creation: A new Spring Boot project (job-ms) is created using Spring Initializr with the necessary dependencies (Web, JPA, H2/PostgreSQL).

2. Code Migration: The job package (containing the controller, service, repository, and entity) is copied from the monolith to the new project.

3. Decoupling the Entity: This is the core of the refactoring. In the monolith, the Job entity likely had a direct object relationship with the Company entity:

   // In the monolith's Job.java
   @ManyToOne
   private Company company;
   

   This creates a hard dependency. The new Job microservice doesn't have a Company class or table. To break this dependency, we replace the object reference with a simple ID:

   // In the new Job microservice's Job.java
   private Long companyId; 
   

   This change embodies the principle of each microservice owning its own data and communicating via identifiers, not shared object models.

4. Independent Configuration: The application.properties file in the job-ms project is configured with its own unique server.port (e.g., 8082) and its own database connection. This ensures it can run as a completely separate process.

3. Reinforcement: Extracting the Company Microservice

Now, let's reinforce the pattern by observing the extraction of the Company microservice. The process is similar, but it further illustrates how dependencies are removed.

By extracting both Job and Company services, we've established two independent services that previously had a direct, coupled relationship.

4. Handling API Design in Decoupled Services

Extracting the Review service introduces a new challenge related to API design. In a monolith, it's common to have nested URLs that reflect entity relationships, like GET /companies/{companyId}/reviews. This URL structure implies that reviews are a sub-resource of a company.

For an independent Review microservice, this URL is problematic because the service should not be bound to the companies path.

API Refactoring Explained

The key change is in how the ReviewController endpoints are defined:

• Monolithic-style URL:
  GET /companies/{companyId}/reviews
  Here, companyId is a @PathVariable. This URL structure tightly couples the Review resource to the Company resource's path.

• Microservice-style URL:
  GET /reviews?companyId={companyId}
  Here, companyId is a @RequestParam. The endpoint belongs solely to the Review microservice's domain (/reviews). It can filter by companyId, but its identity is not dependent on the company path.

This is a subtle but fundamental aspect of designing clean, loosely-coupled microservice APIs.

5. A Practical Tip for Your Workflow

When working with multiple microservices, constantly switching between different IDE windows can be cumbersome. The video offers a helpful tip for managing all your services within a single IntelliJ IDEA window.

Conclusion

In this lesson, we took our first major step into building microservices with Spring Boot. We moved from theory to practice, applying the Strangler Fig pattern to extract three distinct services from a conceptual monolith.

Key Takeaways:

• Incremental Refactoring: We broke down the monolith piece by piece, which is a safer and more manageable approach than a complete rewrite.
• Decoupling is Paramount: The core of the refactoring involved breaking direct dependencies.
  • Data Decoupling: We replaced direct entity relationships (e.g., @ManyToOne) with simple ID fields (Long companyId). Each service should own its data.
  • API Decoupling: We redesigned API endpoints (e.g., from /{companyId}/reviews to /reviews?companyId=...) to make each service's API independent and self-contained.
• Independent Configuration: Each new microservice is a full-fledged Spring Boot application with its own server port and configuration, allowing it to be developed, deployed, and scaled independently.

Now that we have separate, independent services, a new question arises: how do they talk to each other? For instance, how can we get the details of a Company when we only have its ID in the Job service?

In the next lesson, we will begin to answer that. We will explore inter-service communication, starting with synchronous, blocking calls using Spring's RestTemplate.