CHUCK CHUCK 박사

전체 목차

[BACKEND] API를 두 개 켜도 처리량은 그대로였다

620에서 640 req/s. 대신 800 VU의 p95가 10초에서 1.9초로 줄고 시간 초과는 0이 됐다

[BACKEND] 도메인을 사자 쿠키가 Lax로 충분해졌다

vercel.app과 API는 다른 사이트였다. chuckplay.dev로 합치고 나서 막힌 세 가지

[BACKEND] 서버에서 이미지를 굽지 않는다 — blue/green으로 배포 중 실패 0번

GHCR에 올리고, SSM으로 쉬던 색을 띄운 뒤 /health가 200일 때만 Caddy를 돌린다

[BACKEND] 메뉴판은 5초만 믿는다 — 캐시가 비는 순간과 메뉴가 바뀌는 순간

손님 1,000명의 DB 조회를 1번으로. 대신 고친 메뉴는 DEL로 바로 지운다

[BACKEND] 결제 버튼을 잠가도 두 번 빠진다 — 같은 시도에는 같은 번호표

앱이 0.6초에 포기해도 서버의 0.9초 승인은 계속된다. Idempotency-Key로 4번을 1번으로

[BACKEND] 잔액만 고치면 포인트가 사라진다 — 통장 내역이 근거인 이유

적립·사용 200건이 동시에 몰리자 10,100P가 증발했다. 내역 합계와 비교하니 개수가 보였다

[BACKEND] 클릭 1만 건 — 느린 이유는 요청 수가 아니라 커밋 횟수였다

하나씩 18.7초, 100개씩 묶으면 0.29초. create와 createMany를 같은 MySQL에서 비교

[BACKEND] 로그인이 만료된 순간 요청 5개 — 리프레시 토큰은 왜 한 번만 써야 하나

액세스 토큰은 메모리, 리프레시 토큰은 httpOnly 쿠키. 회전, 재사용 감지, single-flight

[BACKEND] 표 100장에 500명 — 선착순 동시성 제어 4가지를 직접 재 봤다

대책 없음, 비관적 락, 낙관적 락, 원자적 UPDATE. 같은 MySQL에서 몇 장이 팔리고 몇 초가 걸렸나