| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
- 재고 시스템
- 부하테스트
- CaffeineCache
- 지연로딩
- 트랜잭션
- Spring Data Redis
- ci/cd
- 상태패턴
- nonclustered index
- method area
- 리팩터링
- backend
- Redis
- 웹캐시
- JDK14
- 동시성
- JAVA8
- springboot
- 제네릭
- Metaspace
- Ehcache
- 주문
- GithubActions
- java
- Jenkins
- 공변
- lazyloading
- B+TREE
- JPA
- 카카오 화재
- Today
- Total
목록주문 (2)
NDM
6. 재고 감소 -> 주문이 맞을까, 주문 -> 재고 감소가 맞을까?
배달 서비스를 구현하는 slowDelivery 프로젝트 진행중입니다. 주문 로직에 대해 제가 고려한 것을 포스팅 하려고 합니다. 도메인은 장바구니 / 상품/ 재고 / 가게 / 주문이 있으며, 결제API는 클라이언트쪽에서 연동하기 때문에 결제데이터를 save하는 정도로만 구현했습니다. 장바구니와 재고는 Redis로 되어있으며, 나머지는 RDB를 사용했습니다. 재고에 Redis를 사용한 이유는 https://ndm-tech.tistory.com/34 에 기록해 두었습니다. 이번 포스팅에서는 아래의 내용을 다룹니다. 주문 로직의 순서를 결정하게 된 고민 과정 프로젝트를 진행하며 처음에 고생했던 부분은 주문이 성공하고 나서야 재고를 감소시켰었다는 점 입니다. 이것은 실제 상황과 비교해 볼 때, 가장 유사한 순서..
5. 주문 트랜잭션 설계와 Transaction 내부에서의 호출 문제
배달 서비스를 구현하는 slowDelivery 프로젝트 진행중입니다. 주문 로직에 대해 제가 고려한 것을 포스팅 하려고 합니다. 도메인은 장바구니 / 상품/ 재고 / 가게 / 주문이 있으며, 결제API는 클라이언트쪽에서 연동하기 때문에 결제데이터를 save하는 정도로만 구현했습니다. 장바구니와 재고는 Redis로 되어있으며, 나머지는 RDB를 사용했습니다. 제 프로젝트의 주문 제한사항은 다음과 같습니다. 장바구니를 거쳐서만 주문할 수 있으며, 장바구니에 다른 가게의 상품을 담을 수 없습니다. 주문 로직의 순서 주문은 다음과 같은 순서로 이루어집니다 장바구니와 가게 데이터를 조회해 주문 객체를 만듭니다. 가져온 데이터로 검증을 시작합니다. ( 가게가 오픈했는가 / 주문 금액이 가게의 최소주문금액을 넘어섰는..