ARCHIVE
아카이브
전체 27개
최신순
- 09 / 16 운영 업무 처리를 AI에게 맡기며 그은 선
- 08 / 14 배포할 때마다 끊기던 지급 처리 떼어내기
- 07 / 03 완주한 작업만 남기던 로그와 사라진 실패
- 06 / 05 매일 2,000건을 버리던 배치에 백프레셔 넣기
- 05 / 08 세 서비스에 흩어진 분산락을 하나로 통일하기
- 04 / 10 환급 배치를 사용자 단위로 쪼개고 멱등하게 만들기
- 03 / 13 펌뱅킹 출금과 내부 원장을 맞추는 하루 단위 대사
- 01 / 13 흩어진 알림톡 발송을 서버 하나로 모으기
- 11 / 17 PG 플랫폼을 두 번 갈아엎고 떠나며
- 10 / 20 혹시나 해서 둔 배치에 진짜로 걸렸다
- 09 / 15 사내 설정 서버에 묶여 있던 테스트 떼어내기
- 08 / 18 227줄이 된 전역 예외 처리를 갈래별로 가르기
- 07 / 21 목록 대신 Redis 만료로 동시 접속 세기
- 06 / 16 월 15,000건 정기 결제의 중복 승인·과거 정산 변동·재시도 쏠림 막기
- 04 / 21 최종적 일관성을 검증하는 결제·정산 대사
- 03 / 17 실패한 메시지 하나가 파티션을 계속 막았다
- 02 / 17 결제와 정산을 분리하면서 생긴 데이터 정합성 문제
- 01 / 20 모놀리식으로 만든 PG를 다시 MSA로 나눈 이유
- 10 / 21 PG 시스템 보안 심사에서 마주친 104개의 보안 이슈
- 09 / 23 실패와 Timeout까지 포함한 금융 결제 테스트 범위
- 09 / 09 무중단 개인정보 암호화와 함께 깨진 검색·정렬·조인
- 08 / 19 장애를 가장 먼저 알려주는 사람이 고객이었다
- 07 / 22 배포에 45분 걸리던 PG를 3분 만에 배포하기까지
- 06 / 17 결제 API 응답속도를 30% 개선하면서 배운 SQL 튜닝
- 05 / 20 연 3,000억 결제 시스템을 Spring Boot로 전환하며 세운 원칙
- 05 / 06 레거시 테이블 300개에서 옮길 것만 남기기
- 04 / 15 레거시 PG 플랫폼을 Spring Boot로 전환하게 된 이유