A
약 90초
경험 중심 1인칭 답변
팀 프로젝트에서 주문 처리 시스템에 비동기 Event Driven Architecture를 적용한 경험이 있습니다. 초기에는 REST 동기 방식으로 연결했는데, 결제 요청이 몰릴 때 응답 지연이 재고 차감 서비스 전체로 전파되는 문제가 생겼습니다. 이후 Kafka를 도입해 주문 이벤트를 큐에 적재하고 각 서비스가 독립적으로 소비하는 방식으로 전환했습니다.
서비스 간 결합을 끊어내니 한 서비스 지연이 다른 서비스에 영향을 주지 않게 됐고, 처리 속도도 개선됐습니다. 다만 이벤트 순서 보장이 필요한 구간에서는 파티션 키 설계를 잘못하면 순서가 뒤집히는 문제가 생겨서, 주문 ID를 파티션 키로 고정하는 방식으로 해결했습니다.
EDA 전환 효과는 트래픽 집중 구간에서 가장 분명하게 드러납니다. 앞으로도 서비스 간 결합을 먼저 끊어내고 비동기 큐를 도입하는 방식으로 EDA를 설계하겠습니다. 이벤트 순서 보장이 필요한 구간을 사전에 식별하는 것이 EDA 전환에서 가장 먼저 해야 할 작업입니다. 파티션 키 설계 오류가 순서 역전을 조용히 만드는 가장 흔한 실수임을 기억하겠습니다.
이 결의 특징
전환 성공담에 그치지 않고 파티션 키 설계 실수로 순서가 뒤집힌 문제까지 짚는 결이다. 트래픽 집중 구간에서 효과가 드러난다는 조건까지 명시한다.
이 결이 통하는 자리
아키텍처 전환을 장점만 나열하기 쉬운 질문에서, 실제 겪은 함정까지 짚는 답이 통하는 자리다.