Easy

• Graceful shutdown 이란 무엇이며, 언제 사용하나요?
  따로 포스팅해서 공부함. 요약하면 서버 재배포 등 서버가 중단될 때 갑자기 꺼져버리면 기존의 트랜잭션이 있던 것들에 문제가 생길 수 있음. 그래서 기존 작업 중인 건 모두 마무리되면 안전하게 종료하는 방식.
  종료에 따른 시스템의 영향을 최소화 하는 것
  운영체제에서 프로세스 종료를 위한 시그널을 보내면 바로 프로세스를 종료하는 게 아니라 시그널을 받아서 안전하게 종료 처리를 하고 프로세스를 종료하는 것

• Event driven architecture 는 일반적인 개발 방법 (function call) 과 장단점은 어떤 것들이 있나요?
  이것도 요약하면

1. 확장성(결합도가 낮음)
2. 함수의 시그니처를 몰라도 됨.
3. 비동기 처리
4. 근데 복잡함.
5. 메시지가 손실될 수 있음.

Basic

이 기능을 구현하면서 DB 와 통신시 어떠한 transaction propagation, isolation level 을 사용하는게 적절할까요?

거의 대부분의 전파 옵션은 REQUIRED이면 되지 않을까? 생각함.

isolation level을 쓴다는 건 유저 생성 트랜잭션과 포인트 생성 트랜잭션이 분리되었을 때는 가정하는 건가?
그렇다면 이 때의 격리 수준은
READ UNCOMMIITED(읽기 미확정)면 안 됨. 포인트 트랜잭션이 커밋되지 않은 유저 트랜잭션을 읽으면 안 됨. 왜냐면 유저가 없는데 포인트가 생성되면 미아 포인트가 생긴다.
READ COMMITTED(읽기 확정)면 될 것 같다. 어차피 포인트 객체는 user를 읽기만 하면 되니까.
REPEATABLE READ(반복 가능한 읽기) 한 트랜잭션이 읽기를 시작하면 다른 트랜잭션이 수정하지 못하게 한다. 근데 어차피 유저 객체과 포인트 객체 생성 시 유저 객체가 바뀔 일이 없으니까 오버 스펙.
SERIALIZABLE (직렬화 가능)는 아예 트랜잭션이 서로 침범하지 못하는 건데 이것도 오버 스펙

Hard

회원 가입 요청 api 의 request 부터 response 까지 정확한 흐름 (behind the scene) 에 대해 설명해 주세요.

1. 클라이언트가 /auth로 post 요청
2. 컨트롤러에서 서비스로 메시지 보냄
3. 서비스 안에서 동일 유저 아이디가 존재하는지 찾는 메시지를 보냄
4. 있으면 에러를 반환함
5. 없으면 비밀번호를 해싱을 하라는 메시지를 보냄
6. 해싱된 비밀번호로 유저를 생성하라는 메시지를 유저 서비스 객체에 보냄
   1. 트랜잭션이 열림
   2. 유저 레포지토리 객체에 유저 객체를 생성하라는 메시지를 보냄(메모리에만 존재)
   3. 이걸 매니저가 데이터베이스에 저장함.
   4. 유저 생성에 따른 이벤트가 발생됨.
   5. 트랜잭션 닫힘
      1. 포인트의 이벤트 핸들러 작동하면서 포인트 서비스에 포인트 객체를 생성하라는 메시지를 보냄.
         1. 유저 존재 여부를 찾으라는 메시지를 보냄
         2. 유저가 없으면 에러 발생
         3. 유저가 있으면 포인트 레포지토리에 포인트 객체를 생성하라는 메시지를 보냄.
         4. 포인트 객체를 데이터베이스에 저장하고 반환함.
      2. 생성된 포인트 객체를 반환함.
   6. 유저 정보를 반환함
7. 반환된 유저 정보로 유저의 pk와 아이디로 토큰을 발생하라는 메시지를 보냄
8. 토큰은 업데이트하라는 메시지를 보냄
9. 토큰을 반환함.