서비스 설계 내용

• 선택한 기술 및 선택 이유
• 시스템 아키텍처
• 코어 기능의 동작 방식

선택한 기술스택 및 이유

• frontend

  • React vs Next.js

    • (선택) React : 주로 CSR, SPA , 서버 부하 거의 없음, SEO 취약
    • Next.js : SSR / SSG / CSR 혼합, 서버가 화면 생성에 관여, SEO 기본 해결
    • 선정 이유 Next.js 은 디폴트가 서버 컴포넌트인데, 실시간으로 대량의 사용자 요청을 감당해야하는 본 서비스 성격을 고려했을 때 렌더링 책임을 브라우저에 두는 SPA가 훨씬 안정적으로 서비스 트래픽을 처리해줄 것으로 예상함.

  • API fetching : **React Query(**tanstack-query) ****vs fetch vs SWR

    • **(선택) React Query :**서버 시뮬레이션 상태 동기화
      • 대기열에서 주기적으로 Polling 하는 기능 구현할 때 polling / refetch 제어가 용이할 것으로 예상

  • CSS : tailwind vs styled-components vs SCSS

    • (선택) tailwind : 개인적인 취향으로.. 클래스 네이밍에 신경쓸 필요가 없다는게 생산성을 많이 높여준다고 생각해서 선호함.

• Backend

  • 프레임 워크

    • express
    • 선택 : nest.js

  • DB

    • mySQL
    • (선택) PostgreSQL

  • 선정 이유 : 트랜잭션 & 동시성 처리 기능 우세

  PostgreSQL과 MySQL은 모두 강력한 트랜잭션 기능을 제공하지만, PostgreSQL은 기본적으로 완전한 ACID 준수와 강력한 MVCC(Multi-Version Concurrency Control)를 통해 높은 데이터 무결성과 동시성(특히 복잡한 쿼리 및 다수 동시 쓰기/읽기)에 강점을 보이며, MySQL은 InnoDB 엔진 사용 시 ACID를 지원하지만, 버전 및 스토리지 엔진에 따라 기능과 성능 최적화가 달라질 수 있으며 단순 읽기 작업에서 더 가벼울 수 있다.

• Devops

  • Kafka
  • LB : 트래픽 부하 분산

시스템 아키텍처

<aside> ❗

목표

• 무슨일이 있어도 터지지 않는 안정적이고 견고한 WS + WAS 서버
  • 터진다 = 죽는다. 더이상 요청을 처리할 수 없는 상태가 되는 것
• 한정된 자원 내에서 최대한 동시에 많은 인원을 수용할 수 있는 서비스 제공
  • 사실 1차원적으로 생각했을 때 “서버 늘리자” 가 해결책이 될 수 있음
  • 사실 자원의 한계 없이 서버를 무한대로 늘릴 수 있다면 얼마든지 대규모 동시 인원을 수용 가능할 것이기 때문에 ‘한정된 자원’ 이라는 제약 조건을 추가함. </aside>