Eventual Consistency

서비스마다 자기 저장소를 갖는 구조에서 모든 변경을 즉시 한 번에 맞추려 하면 네트워크 지연과 장애가 곧장 전체 요청 지연과 실패로 번집니다. 멀리 떨어진 시스템이 잠깐 느리다는 이유로 로컬 업데이트까지 막혀 버리면 가용성이 크게 떨어집니다. 반대로 조정을 완전히 포기하면 상태가 영원히 어긋날 수 있습니다. 분산 시스템은 결국 즉시 일치와 운영 현실 사이 어디에 선을 그을지 결정해야 합니다.

초기 기업 시스템은 하나의 데이터베이스와 강한 트랜잭션으로 많은 문제를 해결할 수 있었습니다. 하지만 마이크로서비스, 글로벌 분산, 비동기 파이프라인이 보편화되면서 모든 경계를 하나의 즉시 일치 모델로 묶는 비용이 커졌습니다. 네트워크 파티션과 지연을 완전히 없앨 수 없는 현실에서, 로컬 성공과 전체 수렴을 분리해 생각하는 방식이 널리 받아들여졌습니다. Eventual Consistency는 바로 그 현실을 인정한 설계입니다.

보통 한 서비스가 먼저 자기 로컬 상태를 커밋하고, 그 변경 사실을 이벤트나 메시지로 다른 서비스에 전파합니다. 다른 쪽은 약간 늦게 그 변화를 반영하므로, 짧은 시간 동안은 읽기 결과가 서로 다를 수 있습니다. 이 구간을 시스템은 정상 상태의 일부로 취급해야 하고, 필요하면 재시도, 보상, 재조정 작업으로 최종 상태를 맞춥니다. 즉 구조 자체가 시간차와 불일치 창을 전제로 설계됩니다.

단일 데이터베이스 안의 ACID 트랜잭션과 달리, Eventual Consistency는 경계 밖 시스템까지 즉시 잠그지 않습니다. 따라서 더 높은 가용성과 느슨한 결합을 얻는 대신, 사용자는 잠깐 오래된 값을 볼 수 있고 개발자는 그 전파 지연을 설명할 수 있어야 합니다. 이것은 그냥 느슨하게 처리하는 것이 아니라, 어느 불변 조건은 즉시 지키고 어느 조건은 나중에 수렴시킬지 명시하는 작업입니다. 전역 즉시 정확성이 절대적으로 필요한 도메인에는 맞지 않을 수 있습니다.

주문 생성 후 배송 시스템과 분석 시스템이 조금 늦게 따라오거나, CQRS 읽기 모델이 쓰기 모델보다 뒤에서 갱신되거나, 여러 지역에 걸친 시스템에서 같은 데이터를 각자 복제해 쓰는 상황에서 자주 등장합니다. 중요한 것은 지연 창을 숨기지 않는 것입니다. '처리 중' 같은 상태를 사용자 경험에 반영하고, 보상과 재조정 도구를 함께 준비해야 실제 운영에서 버틸 수 있습니다.