0) measureable 수치
tps
- transaction per sec qps
- query per sec1) DB 설계
-> DB Lock vs 더블 부킹(중복 예약)
2) newsfeed push or pull 모드 장단점
3) API 명세서를 두고 이야기
: REST API 관련 설계 양식대로, 엔티티 순서 등
-> gitbook 으로 정리
4) Notification 스케쥴러
: spring batch 알아보았지만 실시간 trigger의 존재가 없었음 vs AWS step function 기능
: scheduler(Quartz) 알아봄
5) 중요 엔티티 설정 : DB 매핑
그 바탕으로 ERD 설계, 핵심은 1:N, N:N 양방향 매핑
1) 알고리즘 공부
5) 프로젝트
readme.md로 작업한 거 피드백해주심.
1) 잘못된 표현들 정리
2) ERD 설계
카테고리, point, 2인실 필드 등 지우는 게 낫다.
핵심 빼고는 안하는 게 나아!
StudyGroup-Room 관계 다대다인지 일대일인지?
결론 : 연관관계가 없는 걸로 따로따로, 중간에 Reservation이 있기 때문에.
3) API 명세서
room/{roomId}reservation/{reservationId}
: @PathVariable 엔티티 식별자 id 넣는 주소로!4) 스케쥴러
5) 더블 부팅
멘토님과 <ward-study 프로젝트> 기술면접식으로 질문과 답변이 오갔다. 예상대로 역시나 빡셌다.. 3주차
UseCase 정책에 대한 피드백도 너무 왜?라는 한다디에 정확하게 설명 못함. 시무룩해진다.
🤢 예를 들어, 리더는 스터디그룹 3개를 만듦 ? 굳이 왜?
DB로 더블부킹을 막는 방법에서 내가 생각한 방법이 계속 반려된다. 슬슬 너무 스트레스 강도가 심해진다 느낌.
스프링 배치도 반려 리얼타임이 꼭 필요한 기능으로 생각해야되는지도 의문. 하지만 비동기식 MQ 방식으로 괜찮다고 생각함.