요약 로직 보완

현재 숏캡은 숏폼 동영상을 요약할 때 Asynchronous Requert-Reply Pattern을 사용하고 있다.

요약 작업을 시작함과 동시에 redis에 요약 상태를 저장한다.
클라이언트는 요약 상태 확인 api를 통해 상태를 확인할 수 있고, 요약이 완료되면 서버는 요약 정보의 PK를 반환한다.

이후 클라이언트는 요약 정보 API를 사용해 정보를 가져올 수 있다.

해당 로직을 구현하며 자신만만한 상태였지만, 프론트 팀원에게 연락이 왔다...

요약 요청을 보내고,, 시간이 어느정도 지난 후 상태를 확인하면 500 에러가 떠요

얘기를 들어보니 프론트는 다음과 로직을 사용한다고 한다.

• 사용자가 숏폼 동영상을 숏캡으로 공유하면 요약 요청을 보냄.
• 이후 사용자가 숏캡을 실행하면 상태를 확인 후 요약 정보를 가져온다.

내가 생각했던 로직은 다음과 같다.

• 사용자가 숏폼 동영상을 숏캡으로 공유하면 요약 요청을 보냄.
• 백그라운드에서 일정한 간격을 두고 상태 확인 요청을 보낸다.
• 요약이 완료됐다면 정보를 가져온다.

이 때, 60초 안에는 클라이언트가 pk를 가져갈 것이라 생각해 캐싱된 정보의 ttl을 60초로 설정했다.

@Getter
@AllArgsConstructor
@NoArgsConstructor
@Builder
@RedisHash(value = "videoSummaryStatus", ttl = 60L)
public class VideoSummaryStatusCache {
    @Id
    private String id;
    @Indexed
    private String videoCode;
    .....

하지만 서로 생각했던 로직이 상이했고, 아래와 같이 보완했다.

    // ttl 제거
    @RedisHash(value = "videoSummaryStatus")
	public class VideoSummaryStatusCache {
    	@Id
    	private String id;
    	@Indexed
    	private String videoCode;
    .....
    }
    
    public VideoSummaryStatusResponse getStatus(String videoCode) {
        VideoSummaryStatusCache statusCache = summaryStatusCacheRepository.findByVideoCode(videoCode).get();
        if (statusCache.getStatus().equals("COMPLETE")) {
            // DB에 저장하는 로직
            
            summaryStatusCacheRepository.delete(statusCache);
        }
        return VideoSummaryStatusResponse.from(statusCache);
    }

캐싱된 정보를 ttl이 아닌, 클라이언트가 pk를 가져갔는지 여부에 따라 삭제하게끔 했다.

느낀 점

서로 api 명세서만 공유한 채로 개발을 시작했지만 생각했던 로직이 달라서 생긴 일이다.
평소 프론트엔드와 백엔드는 api만 공유하고 각자의 로직은 알 필요가 없어야한다고 생각했다.
앞으로 로직을 짜기 전, 팀원의 입장에서 한번 더 생각해야할 것 같다.