아키텍처

[스타트업/기술] Sleuth 프로토타입에서 프로덕션까지 | 전체 포스팅 모음

Sleuth는 플레이어가 AI 용의자와 직접 대화하며 단서를 모으고 범인을 지목하는 모바일 추리 게임이다. 6명이 함께 만들고 운영하며, 나는 공동창업자로서 백엔드와 LLM 인프라, 결제, 콘텐츠 제작 도구를 주로 맡았다. 이 글은 Sleuth를 만들며 쓴 기술 글 17편을 한 곳에 모은 목차다. 1절에는 구성도로 전체 모양을 보고, 2절에 개발 과정에서 주로 고민했던 대표 작업 세 가지를 기록해두었다. 3절은 17편 전부를 서비스 개발 …

hyeon_B•

[스타트업/기술] 알림함 아키텍처: Fan-out on Write vs Fan-out on Read | 비용을 '구독자 수'가 아닌 '활성 유저 수'에 비례시키기

문제 푸시 알림은 놓치면 끝이라 사용자별 알림함이 필요했다. 그런데 모든 발송을 서버가 알림함에 펼쳐 쓰면 쓰기 건수가 수신자 수만큼 늘고, 언어별 토픽처럼 서버가 수신자를 모르는 발송은 펼칠 수조차 없다. 결정 서버가 수신자를 uid로 풀 수 있는 발송(uid 지정, 세그먼트, 동의 기반 토픽)은 발송 시점에 서버가 알림함에 쓰고, 풀 수 없는 언어 토픽( lang-* )과 가입 환영 공지만 앱이 열릴 때 클라이언트가 채운다. 대가…

hyeon_B•

[스타트업/기술] FastAPI와 클라우드 네이티브 | Cloud Run 도입과 백엔드 전환기 (Part 2)

문제 트래픽이 없어 인스턴스가 0개일 때 첫 메시지를 보내면 컨테이너 기동과 Firestore 적재가 겹쳐, 응답까지 15.3초가 걸렸다(Cloud Run 요청 로그 1건). 결정 최소 인스턴스를 두지 않고, 서버 기동 시 스토리 데이터를 메모리에 적재하고, 프롤로그 진입 시 앱이 예열 요청( /health )을 보내도록 했다. 대가 예열한 인스턴스가 실제 채팅 요청을 받는다는 보장은 없다. 인스턴스마다 캐시를 따로 들고 있어서, …

hyeon_B•
게시물 더보기
검색결과 없음