A practical guide to building scalable microservices, ensuring data consistency, and operating in production.
버전 번호 기반의 낙관적 락은 "순서가 맞는지" 를 검사합니다. 하지만 비즈니스 로직에는 순서와 무관하게 절대로 위반해서는 안 되는 조건 이 존재합니다.
"채팅방에 동일 인물을 중복으로 초대할 수 없다"
이 조건은 버전 체크로는 보호할 수 없습니다. 버전이 올바른 순서로 처리되더라도, 두 Consumer가 동시에 "이 사람이 이미 존재하는가?"를 조회하고 둘 다 "없다"는 결과를 받은 뒤 동시에 INSERT를 시도하면 중복이 발생합니다.
이런 비즈니스 불변 조건(Business Invariant) 이 있는 경우, 이벤트 기반 비동기 처리보다 DB 상태 확정 후 이벤트를 발행하는 방식이 더 안전합니다.
❌ 비동기 방식 (위험)
초대 요청 이벤트 발행 → Consumer가 중복 체크 → INSERT
(두 Consumer가 동시에 "없다" 판정 → 중복 INSERT 가능)
✅ 동기 방식 (안전)
초대 요청 → DB에 즉시 반영 (UNIQUE 제약 조건으로 보호)
→ 성공 시에만 이벤트 발행 (알림, 후속 처리 등)
언제 비동기를 포기할 것인가
모든 것을 이벤트 기반으로 처리하려는 유혹이 있습니다. 하지만 다음 조건 중 하나라도 해당된다면, 해당 처리는 동기적으로 DB에 먼저 반영하는 것이 맞습니다.
이벤트 기반 아키텍처는 "결과적으로 처리되어도 괜찮은 작업" 에 강합니다. 알림 발송, 로그 기록, 통계 집계 같은 것들이죠. 반면 "지금 이 순간 정확해야 하는 작업" 은 여전히 동기 처리가 맞습니다.
EDA의 핵심은 모든 것을 비동기로 바꾸는 것이 아닙니다. 비동기로 처리해도 안전한 것과 그렇지 않은 것을 구분하는 것입니다.