#backend

상태를 바꾼 트랜잭션은 커밋됐는데 거기 딸린 메일은 fire-and-forget로 날아가 조용히 실패한다. Kafka·SQS 없이 MySQL 테이블 하나로 외부 발송을 트랜잭션에 묶고, 재시도·멱등·DB 장애의 역설까지.

부모(회사)만 soft-delete하고 자식(직원) 테이블을 보존했더니, 삭제된 회사의 ID를 아는 사용자가 권한 검사를 그대로 통과했다. 접근제어가 자식을 직접 조회했기 때문이다.

INV-2026-00001 같은 채번은 유일·연속이어야 한다. 동시 발급 둘이 같은 번호를 받으면 회계 사고다. SELECT MAX+1도 비관적 락도 아닌, 단일 upsert로 직렬화하는 LAST_INSERT_ID 원자 카운터.

mock 유닛 테스트가 전부 초록인데 운영에서 동시 요청에 잔액이 음수가 됐다. 락도 트랜잭션 격리도 원자성도 mock엔 없다. 돈과 무결성이 걸린 코드는 mock green을 통과로 인정하지 않기로 했다.

요청 하나가 수십 줄 로그를 남기는데 서로 연결고리가 없으면 동시 요청에 뒤섞여 추적 불가다. 외부 라이브러리 없이 Node 내장 AsyncLocalStorage로 Correlation ID를 깔고, 로거 64곳을 무수정으로 묶었다.

증권사 API에 종속된 일임계약을, 증권사마다 다른 상태와 규격과 업무 중단을 견디게 설계해야 했다. 증권사별 상태기계, DB 락 대신 Redis 동시성, 큐 기반 중단 대응으로 갈랐다.

인증을 전수 점검하다 같은 구멍이 반복해서 나왔다. 상태 검사는 로그인에만 있고 토큰은 그 검사보다 오래 산다. 정지된 계정이 refresh로 새 토큰을 받고, 검증 토큰은 평문으로 DB에 누웠다.