1. 정해진 재고 만큼만 주문
   1. 동시성을 제어한다.
   2. 재고에 대한 Atomic 한 처리가 필요하다.
   3. 재고는 Durability가 중요하다.
   4. 이전 Coupon System 에서 했던 Redis Set을 이용하는 방식은 한계점이 존재한다.
   5. 재고에 Locking 하면서도 갱신 손실을 대비하기 위한 CAS 연산이 필요하다.
2. 주문과 결제는 무조건 묶어서 원자성 보장
   1. 하나의 트랜잭션으로 묶어야됨
3. 주문과 결제는 시간이 너무 오래 걸려서는 안됨
   1. 이때 결제는 HTTP Request가 필요함
      1. 결제사,PG..
   2. 외부와 통신하면서도 성능과 Tx를 유지해야됨 → transactional outbox pattern

키워드

• 동시성 제어 - Redisson + 낙관적 락
• Transaction
• 정합성 (transactional outbox pattern)

이전 Redis Set은 성능 위주, 지금은 영속성이 중요

그럼 Redis가 영속성에 안좋느냐?

방식을 제공하긴함. RDB/AOF RDB와 AOF

RDB: Copy On Write 방식을 취함

→ 부모 프로세스와 비교 뒤 변경사항을 자신의 것으로 함

Redis 의 메모리 사용량이 폭증함

AOF: Buffer에 데이터를 쓰고 데이터 변경 이후 Disk에 쓰는 방식

장애로 Down 후 Failback 했을 때 해당 데이터는 Disk에 쓰여지지 않았기에 복구할 수 없음

설정에 따라 주기를 선택할 수 있지만 빠를수록 Disk I/O많아짐

++ 추가

이를 위해 redis의 cluster /sentinel 을 사용할 수 있지만 (우선 데이터를 slave에 보내고 aof에 쓰기 때문)

redis 는 async 방식으로 replicaiton 하며 최초 sync 이후 모든 write 명령을 전송하는데 이때 slave는 데이터를 받았는지 전송 결과를 ack 하지 않기 때문에 데이터 gap은 분명 존재할 수 있음