Lesson 1: The “Good” Problem

You have too many users. Your single database is melting. It’s time to scale.

The Bottleneck

Our monitoring (Module 5) shows that Inventory checks are 80% of the database load.

The Refactor: Splitting the Monolith

We decide to extract Inventory into its own microservice with its own database.

Step 1: Update the Architecture

We change Inventory from a logical domain inside the monolith to a physical system.

// Before
domain Inventory { ... }

// After
system = kind "System"
container = kind "Container"

InventoryService = system "Inventory Microservice" {
API = container "Inventory API"
Database = container "Inventory DB"
}

Step 2: Update the Architecture

The OrderService can no longer call Inventory functions directly. It must make a gRPC call. Update your OpenAPI specs to reflect the new gRPC interfaces.

import { * } from 'sruja.ai/stdlib'


OrderService = system "Order Service" {
// ...
OrderService -> InventoryService "gRPC CheckStock"
}

Why Sruja helps

Refactoring is dangerous. Sruja helps you visualize the impact of the change before you write code. You can see exactly which other systems depend on Inventory and ensure you don’t break them.