public class IndividualMatch {
	
	//...

	// 신청 가능 상태(실제 DB적용 x)
	    @Transient
	    private String status;
	
	    public void setStatus(String status) {
	        this.status = status;
	    }

	//...

}

개요

• 마감 여부는 실시간으로 변하는 정보로, DB에 직접 저장하기보다 백엔드에서 로직을 작성하여 처리
• 실제 예약 인원을 계산하려면 IndividualMatchRequest 테이블에서 해당 매치(IndividualMatchId)에 대한 요청의 개수를 세야 함
• 동일한 IndividualMatchId를 가진 IndividualMatchRequest의 레코드 수가 실제 예약 인원을 나타냄

메모리 기반 캐싱 시스템 사용 고려

• 자주 조회되는 데이터를 메모리에 저장해두어 빠르게 접근할 수 있음. (ex. Redis, Memcached)이는 데이터베이스에 대한 부담을 줄여주며, 응답 시간을 단축시켜 사용자 경험 향상에 도움이 됨

캐싱 시스템 사용 상황

• 자주 변경되지 않으면서 자주 조회되는 데이터가 있는 경우
  • 한 번 계산하거나 조회한 후 그 결과를 캐시에 저장해두고 재사용하는 것이 효율적. 대량의 요청을 처리해야 하는 경우, 많은 양의 요청이 동시에 들어올 때, 모든 요청을 실시간으로 처리하기보다는 일부 요청 결과를 캐시에서 가져오는 것이 서버 부하를 줄일 수 있음

주의 사항

• "마감 여부"와 같은 실시간으로 변하는 정보를 캐싱하는 것은 주의가 필요
  • 이 정보가 변경될 때마다 캐시도 함께 업데이트 해야 하며,이로 인한 복잡성과 오버헤드가 발생할 수 있음. 따라서 "마감 여부"와 같은 정보를 캐싱하기 전 다음과 같은 점들 고려했어야 함. 얼마나 자주 이 정보가 변경되는지, 각 변경 사항에 따른 업데이트 비용(캐시 업데이트 포함)은 어느 정도인지,해당 정보를 실제로 조회하는 빈도와 패턴 등

마감 여부 결정 방법

• 해당 IndividualMatch의 playerNumber(예약 가능 인원)을 조회
• 동일한 IndividualMatchId를 가진 IndividualMatchRequest의 개수(실제 예약한 인원 수)를 조회
• 두 값을 비교하여 마감 여부를 결정