채팅관련 상세 아키텍처 설계

[koh-maggie]

기능 설명

• 채팅 구현 아키텍처

부가 설명

• 채팅방 생성

  채팅 API 서버 -> PostgreSQL 채팅방 정보 저장

• 실시간 채팅

  웹소캣 서버 -> Message Broker (Redis, Kafka 등..) -> 컨슈머 서버 -> MongoDB 에 저장

• 채팅 알림 및 채팅 목록 우선순위

  웹소캣 서버 (WebFlux) -> Redis 에 저장( 사용자, 채팅방ID, 내용) -> FCM 히트율 높게 가장 최근 기록으로 저장

• 채팅 목록

  채팅 API 서버 -> MongoDB 조회

[koh-maggie]

• 채팅방 생성

  채팅 API 서버 -> PostgreSQL 채팅방 정보 저장

• 실시간 채팅

  웹소캣 서버 -> Message Broker (Redis, Kafka 등..) -> 컨슈머 서버 -> MongoDB 에 저장

• 채팅 알림 및 채팅 목록 우선순위

  웹소캣 서버 (WebFlux) -> Redis 에 저장( 사용자, 채팅방ID, 내용) -> FCM

• 채팅 목록

  채팅 API 서버 -> MongoDB 조회

[koh-maggie]

• Message Broker 를 Redis 를 사용할 경우, 전송 보장이 되지 않는다는데, 전송이 되지 않는 건의 대해서 재전송 가능한 설정이 있는지 확인 필요

• 채팅 목록을 API 서버에서 조회하는게 맞나 ?

[shinseongsu]

채팅 목록 API로 조회하는것 맞음.

그림도 그려줘요...

[koh-maggie]

@shinseongsu 답변 감사해요. 오케이 그려서 올릴게요 🫡

[koh-maggie]

• 아키텍처 그림 추가 완료

[shinseongsu]

FCM 알림 정보는 늦게 줘도 상관없을 것같은데, redis 보다는 kafka에 담아서 보내는게 좋을 것같습니다. 채팅 내용은 kafka에 넣는것보다는 redis에서 받은 그대로 저장하면 실시간 성으로 보낼수 있을것같아요~

[koh-maggie]

@shinseongsu FCM 알림 정보는 공유주신대로 kafka로 변경해서 하는 것에 공감합니다. 근데, 채팅 내용 같은 경우 redis 통해서 할 경우, db에 저장되기 전에 유실되면 어쩌죠 .. ?

[shinseongsu]

원래 큐 같은걸 사용하기전에는 큐도 데이터가 유실되기 때문에 중간에 rdb나 nosql에 비동기로 같이 저장을해놓는경우도 많습니다.

그렇기때문에 retry server와 같이 다시 재전송 서버가 필요한것입니다. 만약 유실을 고려한다면, db에 저장을 했다가 큐에 전달 전이라는 상태값을 저장하고 redis에 mongodb에 저장하는 식으로 작성을 할것이고, 유실이 되었다고 생각하는건 배치나 스케줄링으로 보내는 방법을 생각할것입니다