📌 문제 상황 1. 즉각 요청-응답 프로세스는 외부 서비스와의 connection을 유지한 채 비관 lock을 잡기에, lock으로 인한 다양한 이슈가 외부 서비스로 전파될 위험 존재(ex. deadlock 발생시 connection도 대기) 2. 즉각 요청-응답 프로세스는 타행 이체(은행A→은행B 이체)를 2개의 API(이체 입금 요청 API, 이체 입금 완료 응답 API)로 구현하자는 은행 간 약속(프로토콜)을 무시하는 방법임. 📌 접근 방법과 해결과정 원인 분석 - 그림2 즉, 이체 입금 요청을 비동기로 처리하는 구조의 문제점 재파악. - 입금을 위해 비관 lock을 잡고 Network I/O를 하는 것이 가장 큰 문제라고 파악. - 특히 타행(이체 입금 역할)은 당행(이체 출금 역할)의 이체 내역..
목차 1. [문제 상황] 동기 보다 비동기가 느린 현상 2. [원인 분석] 로컬에서만 일어나는 NIO 3. [해결] 당행과 타행으로 테스트 서버 분리 4. 고민해봐야할 것 ✍️ 사전 지식 용어 당행 : 사용자로부터 이체 요청을 받고, 이체 입금을 진행하는 은행 타행 : 이체 과정에서 출금을 진행하는 은행 당행 이체 : 입금 은행과 출금 은행이 동일한 이체 타행 이체 : 입금 은행과 출금 은행이 다른 이체 OutBox 데이터 : 이벤트나 메시지를 DB에 있는 아웃박스에 저장해서 DB 트랜잭션의 일부로 발행하는 패턴을 Transactinal OutBOx라고 합니다. 서로 다른 서버의 트랜잭션을 관리하고 할 때, eventual consistency를 보장하기 위해 DB 테이블을 메세지 큐로 사용하는 방식을 ..
목차 1. 문제 상황 2. 요구 사항 분석 3. 스케줄링 전략 선정 테스트 환경 스케줄러 전략 간단 요약 스케줄러 전략별 장단점 스케줄러 전략 상세 설명 및 테스트 결과 스케줄러 전략 3번 선택 4. 개선 필요 사항 ✍️ 사전 지식 용어 당행 : 사용자로부터 이체 요청을 받고, 이체 입금을 진행하는 은행 타행 : 이체 과정에서 출금을 진행하는 은행 당행 이체 : 입금 은행과 출금 은행이 동일한 이체 타행 이체 : 입금 은행과 출금 은행이 다른 이체 OutBox 데이터 : 이벤트나 메시지를 DB에 있는 아웃박스에 저장해서 DB 트랜잭션의 일부로 발행하는 패턴을 Transactinal OutBOx라고 합니다. 서로 다른 서버의 트랜잭션을 관리하고 할 때, eventual consistency를 보장하기 위해..
