Overview
This page documents the architectural performance trade-offs observed when moving from a monolithic Spring Boot service to a microservices architecture.
For the full narrative and lessons learned, see the related Medium article.
Architecture Comparison
Monolith
Client ↓ Spring Boot Application ↓ Database
Characteristics:
- in-process method calls
- shared memory
- single deployment unit
Microservices
Client ↓ API Gateway ↓ Service A ↓ Service B ↓ Service C ↓ Database
Characteristics:
- network-based communication
- service boundaries
- independent deployments
Performance Factors
| Factor | Monolith | Microservices |
|---|---|---|
| Service calls | In-process | Network calls |
| Latency overhead | Minimal | Increased |
| Serialization | None | JSON / Protobuf |
| Debugging | Simple | Distributed |
| Deployment | Single unit | Multiple services |
Latency Impact
The main contributors to latency in microservices are:
- HTTP communication between services
- Serialization and deserialization
- Network round-trip time
- Retry and timeout handling
Each individual cost is small, but the cumulative impact can be significant.
Operational Complexity
Microservices also introduce operational requirements:
- service discovery
- centralized logging
- distributed tracing
- monitoring for multiple services
These systems improve observability but also increase system complexity.
Key Insight
Microservices improve team scalability more than system performance.
When designing a system architecture, performance should be considered alongside maintainability, deployment flexibility, and organizational structure.
Summary
Choosing between a monolith and microservices is not a matter of one being strictly better than the other.
It is a matter of selecting the architecture that best matches the system’s scale, complexity, and team structure.
