Microservices · Lesson 2

Monolith vs Microservices Architecture

Comparing Application Architectures

A monolith packages most application capabilities into one deployable unit, while microservices split capabilities into independently deployable services. Neither is automatically better; the right choice depends on team structure, domain boundaries, operational maturity, and scale. Architecture should solve a real constraint rather than follow fashion.

Defining a Service Boundary

A useful service owns a cohesive business capability and exposes a clear contract. The Java example models a small boundary without sharing mutable internal state.

public class CourseCatalogService {
    public String findCourseTitle(String courseSlug) {
        if ("core-java".equals(courseSlug)) return "Core Java";
        return "Course not found";
    }

    public static void main(String[] arguments) {
        System.out.println(new CourseCatalogService().findCourseTitle("core-java"));
    }
}

Architecture Comparison

Common Mistake and Practices

Common Mistake: Splitting a system into services before understanding its domain boundaries. A distributed monolith keeps all the coupling while adding network failures and deployment overhead.

• Start with cohesive boundaries.
• Automate testing and deployment before splitting.
• Give each service clear ownership.
• Design for partial failure.
• Measure operational cost as well as throughput.

Real-World Use Case

A growing academy first ships a modular monolith, then extracts quiz generation when its scaling and deployment needs differ from course content. The boundary is driven by a concrete workload rather than by class count.