면접 스터디 3차 회고

늦었지만 저번주에 진행한 면접 스터디 내용을 복기하려고 한다.

 

ㅈㅎ님과 나 이렇게 발표했다. 

 

ㅈㅎ님 내용은 토스 테크 블로그의 https://toss.tech/article/34481

캐시를 적용하기 까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)

해당 아티클을 발표해주셨다.

 

내용은 

약관 서비스를 캐시 처리를 통해 db 부하를 감소시키려는 목적이었다. 

조건: Strong Consistency를 유지해야 된다.

약관은 개인정보와 밀접하여 철회한 이후에도 개인정보 공유가 되는 문제가 발생하면 안되기에 

 

전략: Look-aside 패턴 

이유: db의 정보가 자주 변경되지 않았기에

만약 db 정보가 자주 변경된다면 다른 방식 고민

 

만료처리: @EnitityListner + @TransactionalEventListener 사용 

내용: db에 커밋된 이후에 캐시가 만료되도록

이유: db commit전에 만료처리를 하는 경우 다른 요청에서 commit 전 데이터를 적재 할 수 있음 

 

한계: after_commit이어도 cache evict 처리가 실패해도 rollback이 안됨

해결: circuit breaker 활용

내용: evict 실패 시, force open 하여 db 조회하도록 함

 

문제: commit 이후 cache를 evcit하는 찰나의 순간에 kafka event를 consume한 곳에서 잘못된 캐시 조회

해결: kafka event를 cache evict 처리 이후에 발생하도록

 

문제: 그래도 commit 이후 cache evict 처리 되기전에 조회하면?

해결: 정책으로 해결(약관 동의 여부는 값이 db에 commit 되는 순간 바로 다음 요청에 db에 저장된 값이 응답되어야 한다.)

 

캐시를 도입하며 기술적으로 트러블을 해결하려고 하기보다는 로직 순서와 정책 정의를 통해 문제를 풀 수 있는 유용한 case였다고 느꼈다. 

 

 

나 

https://www.notion.so/348fa15530f780e08540ec667c89b5f5?source=copy_link

재고 관리 시스템 | Notion

 

면접에 대비하기 위해 재고관리 시스템을 구축해보았다.

여기서 포인트는 동시성 제어, transaction, 정합성(tx outbox pattern) 3가지였다.

 

여기서 배운것은 분산락을 사용하더라도 예외 케이스(타임아웃)이 발생할 수 있기에 

낙관적락을 같이 쓸 수도 있겠구나라는 것을 얻었다. 

 

그리고 재고와 같이 내구성이 중요한 도메인은 redis와 같이 메모리단 보다 db단에서 정합성 관리를 해야된다는 

비즈니스적 중요성을 함께 생각할 수 있었다.