개요 기프티콘 주문 시스템을 구축하며 가장 큰 고민은 “우리 시스템의 DB 트랜잭션과 외부 API(KT 기프티쇼)의 상태를 어떻게 동기화할 것인가?” 였습니다. 네트워크 지연이나 외부 서버 장애가 우리 서비스의 전체 장애로 번지지 않도록 아키텍처를 개선한 과정을 공유합니다. 문제 상황: 모든 것을 하나의 트랜잭션으로 묶었을 때의 리스크 초기 설...

개요 먼저 저희 서비스는 고객이 업무 요청서를 통해 이루미와 매칭된 뒤, 서비스 내 채팅을 중심으로 업무를 진행, 관리하는 구조입니다. 하지만 운영 과정에서 다음 문의가 반복적으로 발생했습니다. 이루미 응답 지연 시 대응 방법 문의 및 환불 요청 결과물 확인 경로 문의 업무 시간 연장 방법 문의 즉, 채팅이 단순 메시지 확인...

개요 프리랜서 매칭 서비스에서 고객의 업무 요청이 올라오면, 여러 프리랜서가 같은 건을 선착순으로 수락합니다. 이때 트래픽이 순간적으로 몰리면 동일한 업무 요청 행(Row)에 락 경합이 집중되면서 응답 지연이 급격히 증가했습니다. 이번 글에서는 DB 락에만 의존하던 구조를 Redis 기반 분산 세마포어(Redisson RPermitExpirable...

개요 업무 매칭 완료, 업무 제안 같은 주요 비즈니스 이벤트가 발생하면 알림톡 API를 호출해야 했습니다. 초기에는 이벤트를 받아 비동기로 외부 알림 API를 호출하는 구조였지만, 장애 상황에서 전송 실패를 안정적으로 복구하지 못하는 문제가 있었습니다. 이번 글에서는 Transaction Outbox 패턴으로 비즈니스 트랜잭션과 알림 발송을 분리하...

개요 제가 다니는 회사는 프리랜서와 고객을 매칭해 주는 서비스입니다. 고객이 업무를 요청하면 해당 업무에 적합한 프리랜서를 찾아 매칭해 주는 방식으로 서비스가 동작합니다. 저희 서비스는 특정 시간대(11:00~13:00, 15:00~17:00)에 트래픽이 집중되는 피크 타임형 서비스입니다. 이 시간대에는 전체 시스템 트래픽이 약 100 TPS 까지...

개요 그로스팀에 합류한 뒤 가장 먼저 부딪힌 문제는 “실험을 하려면 왜 매번 배포가 필요하지?” 였습니다. A/B 테스트는 빠르게 가설을 검증해야 하는데, 기능 on/off, 트래픽 비율 변경, 타깃 조건 수정 같은 작업이 배포 파이프라인에 묶여 있으면 실험 속도가 급격히 느려집니다. 그래서 운영 배포 없이 제어 가능한 Feature Flag 기능...

문제 배경 사내 서비스 배포 직후, 초기 요청 구간에서 p95가 평소 대비 크게 높아지는 현상이 반복적으로 관측되었습니다. 평균 응답시간(p50)은 크게 나쁘지 않았지만, 실제 사용자 입장에서는 첫 진입에서 느린 응답이나 타임아웃을 체감하는 문제가 발생하고 있었습니다. 특히 초기 트래픽에서 다음 현상이 동반되었습니다. 응답시간 p95, p9...

들어가며 “Redis는 RAM 위에서 동작해서 빠른데, MySQL도 메모리에 올리면 얼마나 빨라질까?” 이런 단순한 호기심에서 시작된 실험입니다. Spring Boot 애플리케이션과 MySQL을 조합해 디스크 기반 환경과 메모리 기반 환경의 성능을 비교해 보았습니다. 이번 글에서는 다음 내용을 정리합니다. MySQL을 인메모리 환경으로 구성...

개요 신규 가입 보상(재화)을 노린 매크로 기반 자동 가입이 하루 1만 건 이상 발생했습니다. 문제는 단순 가입 수치가 아니라, 생성된 계정이 특정 계정으로 보상을 집중시키면서 서비스 경제를 훼손한다는 점이었습니다. 이번 글에서는 다음 2가지를 결합해 가입 어뷰징을 원천 차단한 과정을 정리합니다. 네트워크 단: Cloudflare Turns...

개요 코인 거래소에서 운영되는 스테이킹 서비스는 사용자의 예치 자산에 대해 매일 정해진 시각에 이자를 지급해야 합니다. 제가 맡았던 작업은 매일 00시에 최대 5만 명의 사용자에게 이자를 정산하고 지급하는 배치 파이프라인을 만드는 것이었습니다. 처음부터 이 작업을 단순 스케줄러로 처리하기보다, 정산이라는 성격에 맞는 안정적인 배치 처리 구조를 먼저 ...