[Issue & TroubleShooting]

구현 과정에서 예상되는 문제 및 고민, 추후 해결방안을 담을 공간입니다.

Front-End

인터랙션 컴포넌트 - 추첨 이벤트 플로우 모달 간 상호작용

저희 서비스는 5개의 인터랙션 컴포넌트가 있고, 인터랙션 컴포넌트를 추첨 이벤트 플로우 모달이 감싸는 형태로 구성되어 있어요. 추첨 이벤트 플로우 모달에서는, 다음의 기능이 인터랙션 컴포넌트의 종류에 상관없이 들어가요.

• 인터랙션 컴포넌트가 어떠한 방식으로도 “상호작용”된다면, 추첨하기 버튼이 활성화되어요.
• 리셋 버튼을 클릭하면 인터랙션 컴포넌트의 초기 상태가 리셋되어요.

처음에는 각각의 컴포넌트를 감싸는 각각의 모달이 인터랙션 컴포넌트의 상태를 관리하는 것을 고려했었으나, 인터랙션의 방식이 제각기 다르고, 향후 여러 개의 인터랙션이 더 추가될 수 있으며, 인터랙션 자체를 독립적으로 구성할 수 있어야 한다고 생각했어요.

그래서 각각의 인터랙션 컴포넌트에서 reset이라는, 모든 상태를 리셋할 수 있는 함수를 외부에 노출하면 어떨까? 라고 생각했어요. 이렇게 구성하면, 인터랙션 컴포넌트는 자신이 갖고 있는 상태에만 집중할 수 있고, 인터페이스를 통해 외부와 상호작용을 할 수 있어서 응집도가 향상돼요.

이 과정에서, 어떠한 방식으로 reset 인터페이스를 외부에 노출할지가 고민입니다.

모달 관리

저희 서비스는 모달이 많아요. 모달은 독립적으로 열고, 닫을 수 있는 UI적 관심사를 가지고 있으며, 닫기 버튼을 따로 가지고 있어요. 하지만, 모달 안에는 특정한 내용이 들어가야 하며, 모달 내부 컴포넌트에서 어떠한 행동을 하면서 모달을 닫아야 하는 경우도 있어요. 문제는, 모달에 들어가는 요소마다 스타일이 다르고, 닫기 버튼 옆에 기능 버튼이 표시되는 경우도 있으며, 닫기 버튼이 x자로 표시되고 위치가 이동되는 경우도 있었어요.

우리가 직면해야 하는 과제는 크게 2개에요.

1. 어디까지를 UI적 요소로 보아서, 모달 자체 컴포넌트가 무엇까지 가지고 있어야 하는가?
2. 모달을 여는 상태를 어떻게 관리할 것인가?

Back-End

객관적이고 설득력 있는 테스트

순간적으로 요청이 몰리는 선착순 이벤트의 여러 가지 구현 방안을 조사하고 실제로 가볍게 구현하고 있습니다. 크게 다음과 같습니다.

1. Redis의 분산 락을 활용한 상호 배제 요청 처리
2. RabbitMQ 큐잉을 활용한 대기열 기반 요청 처리
3. Redis의 SortedSet을 활용한 대기열 기반 요청 처리

여러 가지 구현 방안 중 어떤 방안이 최적인지 테스트하기 위해서는 메모리나 네트워크 등을 모니터링해야 할 텐데, 실제 EC2에 배포한 서버에 초당 10000번 등의 부하 테스트를 함부로 걸 경우 비용이나 밴 측면에서문제가 발생할 것으로 짐작하고 있습니다.

이렇게 여러 구현 전략을 객관적으로 평가하기 위한 "설득력 있는 테스트"를 위해서는 백엔드 개발진으로서 어떤 요소를 중점적으로 신경써야 할지 여쭙고 싶습니다.

추첨 기능의 확장성

현재 저희에 요구사항에 따르면 유저가 추첨 이벤트에 참여할 때 단순 응모권 외에도 "기대평 작성" 시 응모 가산점을 추가로 부여하고 있습니다.

그러나 "링크 공유" 등 다른 액션으로 응모 가산점을 받을 수 있는 이벤트도 충분히 존재할 수 있습니다.

저희 팀은 애플리케이션 전반적으로 "재사용 가능한 시스템"을 구축하는 것을 목표로 하여, 유저의 다양한 액션을 고려하여 확장성 있는 백엔드 시스템을 설계하고자 합니다.

다만 현재로서는 이러한 부분을 DB에서 처리해야 할 지, 애플리케이션에서 처리해야 할 지 혼란이 있습니다.

이렇게 응모 가산점과 같은 변동 가능성이 있는 부분은 애플리케이션에서 처리하는 것이 바람직한지, 테이블 자체를 더 확장성 있게 설계하는 것에 집중하는 게 바람직한지 조언을 구하고 싶습니다.