서비스의 특성상 채팅이 휘발되지 않도록 저장소를 선택해야 했어요.
우선 RDB와 NoSQL을 고민했어요.
채팅의 경우 데이터가 엄청나게 쌓일 것 같으니 RDB에 저장하게 되면 관계를 관리하기 어려워지고, 성능 저하가 발생할 것 같았어요.
또, 채팅으로 넘어오는 데이터가 단순 문자가 아니라 이미지 등의 내용도 동적으로 받아올 수 있어야 할 수 있을 것 같았어요.
그래서 NoSQL이 이러한 점에서 더욱 유리하고 유연성을 가진 것 같아서 NoSQL로 최종 선택했습니다.
사실 채팅 아키텍처 설계를 어떤 식으로 접근해야할 지 경험이 없어서 시작을 못하고 있었습니다.
그래서 이것 저것 레퍼런스들을 찾아봤지만 ‘메세지큐’, ‘Pub/Sub’, ‘레디스‘, ‘카프카’ 등 처음보는 개념들이 쏟아졌습니다..
또 채팅 서버의 경우 웹소켓 통신을 사용하고, 웹소켓 통신은 하나의 서버에서 받을 수 있는 요청의 수가 제한적이었습니다.
그래서 다중 서버를 고려했어야 했지만, 이러한 고민으로 계속해서 설계 및 개발이 지체되고 있었습니다.
그래서 너무 깊게 생각하지말고 우선 단일서버를 기준으로 socket.io를 이용해서 구현해보기로 결심했습니다!
이후 리팩토링으로 서버를 증설할 수 있도록 고쳐보고자 했지만 아직 진행하지 못했습니다.