Java: What is Microservices architecture?

Microservices — an architectural style where an application is decomposed into a collection of small, autonomous services, each running in its own process and communicating via lightweight mechanisms such as HTTP/REST or message brokers.

System Design Context: Microservices evolved from the limitations of monolithic architectures where a single codebase handled all business functions. As systems grew, monoliths became difficult to scale, deploy, and maintain. Microservices solve this by breaking the system into bounded contexts aligned with business domains (Domain-Driven Design).

Key Principles:

• Single Responsibility — each service does one thing and does it well.
• Independently Deployable — deploy one service without redeploying others.
• Organized Around Business Capabilities — not technical layers.
• Decentralized Data Management — each service owns its database.
• Designed for Failure — services must be fault-tolerant.
• Infrastructure Automation — CI/CD, containerization, orchestration.
• Observability — centralized logging, tracing, and metrics.

Production Components:

• Service Discovery — Eureka, Consul, etcd for dynamic service registration.
• API Gateway — Spring Cloud Gateway, Kong for unified entry point.
• Circuit Breaker — Resilience4j for fault tolerance.
• Config Server — Spring Cloud Config for centralized configuration.
• Message Broker — Kafka, RabbitMQ for asynchronous communication.
• Distributed Tracing — Jaeger, Zipkin, OpenTelemetry.
• Container Orchestration — Kubernetes for deployment and scaling.

1// User Service — a complete microservice example
2@RestController
3@RequestMapping("/api/users")
4@Validated
5public class UserController {
6
7    private final UserService userService;
8    private final CircuitBreaker circuitBreaker;
9
10    public UserController(UserService userService,
11                          CircuitBreakerRegistry registry) {
12        this.userService = userService;
13        this.circuitBreaker = registry.circuitBreaker("userService");
14    }
15
16    @GetMapping("/{id}")
17    public ResponseEntity<UserDTO> getUser(@PathVariable @Positive Long id) {
18        UserDTO user = Decorators.ofCallable(() -> userService.findById(id))
19            .withCircuitBreaker(circuitBreaker)
20            .withRetry(Retry.of("retry",
21                RetryConfig.custom().maxAttempts(3).build()))
22            .decorate()
23            .execute();
24        return ResponseEntity.ok(user);
25    }
26
27    @PostMapping
28    @ResponseStatus(HttpStatus.CREATED)
29    public UserDTO createUser(@Valid @RequestBody CreateUserRequest request) {
30        return userService.create(request);
31    }
32}
33
34// Service with event publishing
35@Service
36@Transactional
37public class UserService {
38
39    private final UserRepository userRepository;
40    private final KafkaTemplate<String, UserEvent> kafkaTemplate;
41
42    public UserDTO create(CreateUserRequest request) {
43        User user = new User(request.name(), request.email());
44        User saved = userRepository.save(user);
45        kafkaTemplate.send("user-events",
46            new UserCreatedEvent(saved.getId(), saved.getEmail()));
47        return UserDTO.from(saved);
48    }
49    
50    public UserDTO findById(Long id) {
51        return userRepository.findById(id)
52            .map(UserDTO::from)
53            .orElseThrow(() -> new UserNotFoundException(id));
54    }
55}

Scaling Patterns:

• Horizontal scaling — add more instances behind a load balancer.
• Database per service — avoid shared databases to prevent coupling.
• Event-driven communication — use Kafka for cross-service events.
• Saga pattern — for distributed transactions.

Common Pitfalls:

• Distributed monolith — services too coupled, must deploy together. Fix: enforce API contracts, use async messaging.
• Data consistency — no ACID across services. Fix: eventual consistency, Saga pattern, outbox pattern.
• Network latency — inter-service calls add latency. Fix: async communication, caching, request batching.
• Service proliferation — too many tiny services. Fix: start with a modular monolith, split when needed.

Monitoring & Observability:

• Track request latency percentiles (p50, p95, p99) per service.
• Monitor error rates and circuit breaker state transitions.
• Use distributed tracing to follow requests across services.
• Alert on database connection pool exhaustion and message queue lag.

Benefits:

• Technology diversity — each service can use different stacks.
• Team autonomy — independent development and deployment.
• Fault isolation — one service failure doesn't crash the system.
• Targeted scaling — scale only the bottleneck service.