SPOT.Ver2

지난 25년 9월부터 스팟의 리뉴얼 서버를 혼자 개발하게 됐다. 가장 먼저 했던 고민은 “어떤 아키텍처로 시작하는게 가장 합리적일까?” 였다. 아키텍처는 단순한 구조 선택이 아니라 이후의 개발 생산성, 유지보수성, 확장 전략을 모두 결정짓는 요소다. 이번 포스트를 통

스팟이 성장한 상황을 가정하여 대략적인 기능들의 성능을 측정했다. 실제 트래픽 패턴을 예상 및 분석하여 스터디 약 300만 건, 좋아요 약 900만 건, 댓글 약 500만 건을 삽입하고 성능을 측정했다. 먼저 스터디 필터링 기능에 대해 테스트를 진행했다. 스터디 리스트

사전 집계 테이블을 업데이트하는 과정에서 동시성 문제가 발생했다. 다수의 요청이 동시에 같은 row를 업데이트하면서 갱신 손실이 발생할 수 있는 상황이었다. 이 문제는 Atomic Update 쿼리를 사용해 해결했다. 단일 SQL에서 값을 증가시키는 방식으로 처리하면서

Redis 기반 Write-Behind 패턴을 도입하며 많은 고민을 했었는데, 이번 포스트를 통해서 어떤 부분을 주의했는지, 또 어떤 위험이 있었는지 한 번 정리해보려고 한다. 먼저, Redis는 인 메모리 기반의 Key-Value 기반 NoSQL이다. 다양한 자료형을