백엔드#배치#장애복구#설계
서버가 죽으면 발송은 어디서부터 다시 해야 하나
대량 푸시 발송 중에 서버가 죽었다. 10만 명 중 6만 명까지 보냈는데 서버가 재시작되면서 상태가 `PROCESSING`에 멈춰버렸다.
11
Blog
개발하면서 배운 것들을 기록합니다.
#AOP#CAS#CompletableFuture#Coroutine#DB#DLT#EIP-2612#FCM#HikariCP#JPA#Java 21#Kafka#Kotlin#Logback#MDC#MySQL#OSIV#OpenTelemetry#Pessimistic Lock#Spring#Spring Boot#Virtual Thread#Web3j#결제#다중서버#대량발송#동시성#로깅#멀티테넌시#메시징#모니터링#배치#배포#버그#보안#블록체인#비동기#상태머신#설계#성능#스케줄러#암호화#에러처리#외부API#장애격리#장애복구#장애분석#커서#토큰#트랜잭션#트러블슈팅#필터
백엔드#로깅#모니터링#설계
로그 한 줄에 요청과 응답을 다 담았다 — ONELINE 구조화 로깅
Spring Boot 기본 로깅은 이런 식이다.
1
백엔드#장애격리#설계#외부API
외부 API가 죽으면 결제도 죽어야 할까?
우리 결제 시스템은 블록체인 거래를 할 때마다 외부 SaaS API에 보고해야 한다. 법적 컴플라이언스 요구사항.
백엔드#블록체인#비동기#설계
DB는 동기, 블록체인은 비동기 — 인센티브 2단계 패턴
사용자가 10,000원 결제하면, 결제 처리 후 인센티브(캐시백)를 지급해야 한다. 인센티브 지급도 블록체인 트랜잭션이니까, 결제 응답이 돌아오기까지 "결제 온체인 처리 + 인센티브 온체인 처리" 두 번의 블록체인 대기가 필요했다.
3
백엔드#블록체인#결제#설계
3개 지갑에서 자동으로 차감하는 Waterfall 결제
→ Waterfall(폭포수) 패턴이란 우선순위가 높은 항목부터 순서대로 소진하고, 남은 금액을 다음 항목으로 넘기는 방식이다. 물이 위에서 아래로 흐르듯이 처리된다.