Event-Driven · Architecture
이으면 생기는 문제들 - 이벤트 패턴 지도
쪼개고 비동기로 이으면 편해지는 대신 새 문제가 생긴다. 중복·발행 누락·분산 트랜잭션·복잡한 조회 - 벽마다 정해진 패턴이 있다. 그 이름들의 지도를 먼저 편다.
느슨하게 잇는다 1편
Architecture · Consistency
나누면 정합성을 잃는다
두 서비스의 숫자가 다르다. CAP는 셋 중 둘을 고르라는 말이 아니고, 실무의 선택은 이분법이 아니라 눈금이다.
어떻게 나누나 6편
Architecture · Event-Driven
Pub/Sub과 이벤트 기반
일을 시키는 대신 일어난 일을 알린다. 듣는 쪽을 몰라도 되는 대신, 흐름이 코드에서 사라진다.
어떻게 나누나 5편
Architecture · Message Queue
메시지 큐 - 기다리지 않게 만든다
지금 안 해도 되는 일을 쌓아두고 나중에 처리한다. 대신 실패가 나중에 오고, 중복이 오고, 순서가 흔들린다.
어떻게 나누나 4편
Architecture · Microservices
서비스끼리 어떻게 부르나
동기 호출은 가장 단순한 답이지만, 한 곳의 느려짐이 전체로 번지는 통로이기도 하다. 타임아웃·재시도·차단기로 그 통로를 좁힌다.
어떻게 나누나 3편
Architecture · Microservices
나누면 무엇이 달라지나
배포·장애·확장 단위를 갈라놓는 대신 네트워크가 끼어든다. 얻는 것과 새로 지는 비용을 나란히 놓는다.
어떻게 나누나 2편
Architecture · Monolith
모놀리스가 먼저다
한 덩어리로 만드는 건 아직 못 나눈 상태가 아니라 정상적인 출발점이다. 무엇이 쉬워지고, 언제부터 아파지는가.
어떻게 나누나 1편
Scaling · Architecture
수직이냐 수평이냐
서버를 키우는 것과 늘리는 것은 난이도가 다르다. 늘리는 쪽이 어려운 이유는 서버가 아니라 서버가 들고 있는 상태에 있다.
부하를 견디는 법 4편