부하테스트와 개선점을 찾아보자 - 10주차
부하 테스트 보고서 부하테스트 시나리오 선정 및 선정된 시나리오의 API 개별 테스트 (리스트) 콘서트 조회 API (GET) /concerts 대기열 생성 API (POST) /queues/enqueue 대기열 조
#항해플러스
트랜잭션의 범위 분석과 비즈니스 개선 방안 - 8주차
결제 유스케이스 트랜잭션 범위 분석 대표적으로 결제 유스케이스를 통해 트랜잭션의 범위를 분석해 보자. 먼저 결제 퍼사드의 비즈니스 로직은 아래와 같다고 가정하자. 위 비즈니스 로직은 크게 두 가지의 문제점이 있다.
Index를 통한 쿼리 성능개선 - 8주차
콘서트 예약 서비스에는 꽤 많은 쿼리가 수행된다. 이번 주차에는 성능 개선할 수 있는 쿼리들을 색출하고, 직접 인덱스를 걸어본 후 성능 비교와 부하테스트를 해 보자. 콘서트 예약 서비스의 조회 쿼리들에 대한 인덱스
콘서트 예약 서비스에서의 동시성 이슈 해결 방안 분석 및 성능 테스트 - 6주차 WIL
항플 백엔드에서, 내가 선택한 주제는 콘서트 예약 서비스이다. 콘서트 예약 서비스에서는 아래와 같은 세 가지의 동시성 이슈 발생 가능성이 있다. 유저의 잔액 충전 유저의 좌석 예약 예약된 좌석 결제 동시성 제어와 동
항해99 플러스 백엔드 Chapter2(3,4,5주차) 회고 및 WIL
3,4,5주차에 걸쳐 Chapter2를 진행했다. 이번 회고에서는 주차별로 어떤 과정을 거쳤고, 어떤 문제점을 겪고 해결했는지를 정리해 보려고 한다. 3주차 3주차에는 서비스 시나리오를 선택하는 과정부터 시작했다.
항해99 플러스 백엔드 2주차 WIL - 클린아키텍처와 동시성
1주차 발제에서는 TDD와 동시성이 주제였는데, TDD는 이제 기본으로 깔고 들어가야 한다. 이번 주차에서는 클린 아키텍처와 동시성이다. 저번 주차의 동시성은 단일 인스턴스라는 가정하에, DB 없이 락을 구현하는게