1. 서비스 요구사항

왜 메시지 큐가 필요할까?

<aside>

커플 서비스의 가장 큰 특징은 폐쇄형 SNS라는 것이다.

즉 커플 두명만 데이터를 주고 받으면 더이상 다른 누구에게 동기화해줄 필요가 없는 것이다.

우리가 데이터베이스를 사용하는 이유는 사용자들에게 데이터를 동기화 시켜주기 위함이다.

하지만 커플 서비스는 서로 간의 데이터 동기화만 이루어지면 DB를 조회할 이유가 아예 없어진다. 사용자는 자신의 디바이스 DB만 조회하면 된다.

DB를 조회하는건 사용자가 자신의 디바이스 DB를 초기화하거나(앱 삭제 등), 재로그인 시 조회한다.

</aside>

배치 업데이트 적용하기

<aside>

사용자가 데이터 동기화를 위해 DB를 조회하지 않는다는 점은 DB를 바로 동기화 하지 않아도 된다는 말이다.

이 점을 이용하여 사용자의 요청이 들어왔을때 이를 REDIS에 동기화해뒀다가 배치 처리하는 것을 고려해볼 수 있다.

단 서비스 요구사항에 맞춰 바로 DB에 반영해야 할 수도 있다.

• 생성 같은 경우는 해당 데이터가 DB에 반영이 안되어 있을때 추후 업데이트 시 문제가 발생할 가능성이 있기 때문에 바로 DB에 반영되게 했다.
• 반면 업데이트의 경우는 배치 처리를 진행했다 </aside>

커플 메시지 큐 아키텍처

<aside>

상황

유저 A와 B가 커플 연결되어 있는 상황이다. A가 일정을 수정하면 이 내용이 메시지 큐를 통해 B에게 전달되어야 한다.

</aside>

<aside>

프로세스

1. A가 일정을 수정하는 요청을 백엔드 서버로 보낸다.
2. 백엔드 서버는 요청을 두가지로 나누어 각각 REDIS에 저장한다.
   • 메시지 동기화를 위한 B 메시지 큐에 저장
   • 배치 처리를 위한 저장
3. B가 서버에 접속했을때 메시지 큐에서 데이터를 가지고와 동기화를 진행한 후 메시지 큐를 초기화한다
4. 백엔드 서버는 배치 처리를 통해 이를 변경사항을 DB에 반영 </aside>

2. 아키텍처 개선

<aside>

해당 아키텍처의 문제점을 하나하나 살펴보자

</aside>

1️⃣ 데이터의 정합성을 보장하는데 문제가 생길 수 있다

<aside>

문제상황

1. 유저 B가 데이터를 동기화 하기 위해 백엔드 서버로 요청을 보냈다
2. 백엔드 서버는 동기화를 위한 데이터를 레디스에서 조회함과 동시에 데이터를 삭제한 후 이를 응답한다
3. 만약 여기서 B가 데이터를 처리하다가 예상치 못한 상황으로 데이터를 처리하지 못한다면 데이터 정합성 문제가 발생한다 </aside>

<aside>

문제해결

메시지 큐를 ACK 기반 큐로 활용하여 유실된 데이터 문제를 해결함으로 데이터의 정합성을 보장

</aside>