Decomposing a Monolith into Microservices with Call Graph Analysis

Decomposing a Monolith into Microservices with Call Graph Analysis

Splitting a monolith into microservices is about finding the right boundaries. Bad boundaries create distributed monoliths, where services cannot be deployed independently. Good boundaries follow natural seams in the code: tightly coupled clusters of functions that are loosely connected to the rest of the system. This post takes the CoolStore monolith, currently running on WebLogic, and applies call graph analysis to identify where to cut it into microservices.

The CoolStore application consists of 25 classes across 5 packages. It handles four main business operations:

- Catalog browsing: list products, check inventory

- Shopping cart: add/remove items, calculate price, handle shipping and promotions

- Order processing: checkout, publish to JMS, MDBs persist the order

- Inventory management: deduct stock on order, issue low-stock alerts

Currently, these operations share a single database, a single JMS topic, and inject each other's EJBs. The goal is to determine which components can become independent services and where the coupling points make that difficult.

Step 1: Build the Call Graph

The first step is to build the function-level call graph using rgctl. This generates a graph with 1,227 files, 17,417 nodes, and 52,920 edges. The analysis detected 13,565 communities (clusters of functions) and identified 186 circular dependencies.

Step 2: Detect Community Structure

Using label-propagation community detection, the call graph is analyzed to find clusters of functions that call each other densely but have sparse connections to the outside. These clusters are candidates for microservice boundaries. The top communities identified are:

1. Community 8064 (30 members): Cart Operations

- Contains CartEndpoint, ShoppingCartService, and related model methods

- Forms a tight call cycle for CRUD operations on cart items

- Includes REST endpoint, service, and price/shipping methods

2. Community 4266 (30 members): Pricing and Shipping

- Contains ShoppingCartService, ShippingService, and PromotionService methods

- Handles total calculation, shipping costs, and promotions

- Calls into ShippingService and PromoService.applyShippingPromotions

3. Community 11973 (18 members): Product Operations

- Contains ProductEndpoint, ProductService, and related model methods

- Focuses on product lookups and catalog details

4. Community 11250 (7 members): Catalog Item Entity

- Contains CatalogService and InventoryEntity methods

- Manages product and inventory data

5. Community 4058 (4 members): Promo Service

- Contains PromoService and Promotion methods

- Deals with applying shipping promotions

6. Community 14643 (5 members): Order Operations

- Contains OrderEndpoint and OrderService methods

- Manages order creation, status, and persistence

Each community represents a candidate microservice boundary, with the circular dependencies serving as potential coupling points that need to be addressed when breaking apart the monolith.