최악의 마이크로서비스 결과는 **"distributed monolith(분산 모놀리스)"**입니다. 물리적으로는 분리되어 있지만 너무 강하게 결합되어 함께 배포해야만 하는 서비스들입니다. 분산의 모든 비용을 치르면서 독립성은 전혀 얻지 못합니다.
✗ 한 서비스를 변경하면 여러 서비스를 함께 재배포해야 함
✗ 서비스가 데이터베이스 / 공유 스키마를 공유
✗ 단일 요청이 많은 동기 홉으로 팬아웃
✗ 릴리스를 팀 간에 조율해야 함
→ 네트워크 + 운영 비용은 치르지만 독립적 배포 가능성을 잃음
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기| 안티패턴 | 문제 |
|---|
| 공유 데이터베이스 | 서비스 재결합; 독립적 스키마 변경 불가 |
| 수다스러운 서비스 | 요청당 많은 동기 호출 → 지연, 취약함 |
| 나노서비스 | 너무 세밀; 오버헤드가 로직을 압도 |
| API 버전 관리 없음 | 한 변경이 모든 소비자를 깨뜨림 |
| 동기 체인 | A→B→C→D를 따라 지연과 장애가 곱셈 |
| 신(God) 서비스 | 모두가 의존하는 하나의 서비스(새로운 모놀리스) |
대개 잘못된 경계입니다. 비즈니스 기능이 아니라 기술 계층이나 엔티티로 분할된 서비스는 수다스럽고 상호 의존적이 됩니다.
나쁨: 하나의 체크아웃을 위해 User-svc, Product-svc, Cart-svc 모두 호출됨
좋음: Checkout이 기능을 처음부터 끝까지 소유
분산 모놀리스는 진짜 모놀리스보다 엄격히 더 나쁩니다. 더 느리고, 디버깅이 더 어렵고, 운영할 것이 더 많은데도 여전히 독립적으로 배포할 수 없습니다.
대부분의 안티패턴은 경계와 공유 데이터베이스로 거슬러 올라가므로, bounded context와 데이터 소유권을 올바르게 잡는 것이 도움이 되는 마이크로서비스와 해가 되는 마이크로서비스를 가릅니다.