Skip to content

Latest commit

 

History

History
82 lines (72 loc) · 6.78 KB

opener-market.md

File metadata and controls

82 lines (72 loc) · 6.78 KB

Assignment - Opener-Market

  • 해당 과제는 총 6개의 Step으로 구성되어 있습니다.
  • 모든 과제는 C4-Cometrue 깃허브 레포에서 관리되어야 하며, 반드시 각 Step이 종료될 때 마다 PR 요청을 날려야 합니다.
    • 물론, 다른 사람들의 PR에 대한 리뷰도 가능합니다.
  • 서버는 편할 때 요청해 주세요.
  • 상당히 고민이 많이 필요한 주제입니다. 일부 Step에 대해서 제공하는 키워드가 힌트가 될 수 있으니, 키워드와 관련한 학습을 진행하는 것을 권장합니다.
  • 궁금증이 있으면 주저하지 말고 서로 커뮤니케이션하고, 그럼에도 해결되지 않는다면 질문을 남겨주세요.
  • 각 PR 마다 설계 의도를 작성해주세요. 좀 더 효율적인 리뷰가 가능할 겁니다.

프로젝트 설명

판매자 - 구매자 관계가 있는 오픈마켓 플랫폼 개발

  • 판매자는 물건을 자유롭게 올리고, 구매자는 해당 물건을 구매할 수 있는 서비스를 만들어 봅시다.
  • Step의 수가 적어 간단해 보일 수 있지만, 상당히 많은 이슈에 대한 고민이 필요한 주제입니다.

Step 1. 판매자, 구매자 기본 세팅

구현사항

  • 기본적인 판매자, 구매자 환경을 구축합시다.
  • 실제 돈을 갖고 거래를 할 순 없는 환경인 만큼, 캐시를 충전해서 구매할 수 있도록 만들어 주세요.
  • 판매자는 물건을 올릴 수 있습니다.
    • 물건을 올릴 때에는 기본적인 상품의 정보 (이름, 설명, 금액)과 판매 가능한 재고의 수를 등록할 수 있습니다.
    • 하지만, 일단 해당 스텝에서는 재고가 음수가 되어도 구매 가능하다고 가정할게요.
    • 판매 수익은 5%의 수수료를 제하고 판매자에게 지급됩니다.
    • 단, 구매자가 거래 확정 버튼을 누르기 전 까지, 지급이 제한됩니다.
  • 구매자는 물건을 구매할 수 있습니다.
    • 캐시를 충전하면, 해당 금액 만큼의 물건을 구매할 수 있습니다.
    • (선택) 실제 간편결제 서비스의 개발 환경을 활용해, 캐시 충전을 직접 하셔도 됩니다.
    • 물건을 구매할 경우 결제 완료 상태로 변하며, 배송 출발 상태가 될 때 까지 환불이 가능합니다.

프로그래밍 요구사항

  • 일부러 결제 프로세스를 대충 설명했습니다. 자연스럽게 필요한 요소를 채워 주세요.

Step 2. 구매 기능 개선

구현사항

  • 구매 기능을 좀 더 단단하게 만들어 봅시다.
  • 물건을 구매할 시, 다음과 같은 프로세스가 진행되어야 합니다.
    • 잔고 차감: 잔고가 빠져 나갑니다.
    • 재고 차감: 재고가 1개 줄어듭니다. 단, 스텝 1과 달리 재고가 없으면 물건 구매가 불가능하고, 해당 물건은 "품절" 상태로 변경 됩니다.
    • 포인트 적립: 결제 금액의 2.5%에 해당하는 금액이 포인트로 들어옵니다.
  • 물건 구매를 진행할 경우, 포인트를 사용할 수 있습니다. 단, 몇 포인트를 사용할지는 사용자가 직접 결정해야 합니다. (1원 이상 사용 가능)

프로그래밍 요구사항

  • 잔고 차감, 재고 차감, 포인트 적립의 구성은 어떻게 이루어져야 할지/실패 시 어떤 방식으로 복구를 진행해야 할지 생각해 보세요.
  • 사실 Step 1과 비교하면 논리적으로 비어있는 부분이 하나 있습니다. Step 1에서 제시한 힌트를 사용하여 문제와 해결 방법을 판단해 보세요.
  • 상당히 어려운 레벨입니다! 적극적인 질의 응답과 논의를 요구합니다.

Step 3. 상품 검색 기능 개발

구현사항

  • 상품 검색 기능을 추가합니다.
  • 검색 키워드는 2글자 이상이어야 하며, 상품 이름에 해당 키워드가 포함될 경우 검색 대상이 됩니다.
  • 검색 결과가 배치되는 기준은 사용자가 설정합니다.
    • 구매 많은 순, 별점 높은 순, 가격이 가장 낮은/높은 순, 최신 순
  • 맞습니다. 상품 리뷰 기능도 추가해야 합니다.
    • 상품 리뷰는 1 ~ 5점으로 구성되어 있으며, 해당 물건을 구매해야만 작성할 수 있습니다.

프로그래밍 요구사항

  • 단순 기능 구현 자체는 어렵지 않지만, 데이터가 많으면 많아질수록 "잘" 구현하는 것이 중요해지는 Step 입니다. 어떤 점을 고려해야 할까요?
  • 직접 데이터를 수천개, 수만개 정도 생성해서 Naive한 구현 결과와 최적화 한 구현 결과를 비교해 보세요.

Step 4. 할인 쿠폰 발급

구현사항

  • 이벤트를 통해 할인 쿠폰을 발급하려고 합니다. 쿠폰의 종류는 다음과 같습니다.
    • 선착순 발급 쿠폰: 선착순으로 발급 가능한 쿠폰입니다. 유효기간 내에 언제든 사용할 수 있습니다.
    • 선착순 사용 쿠폰: 쿠폰 발급은 자유로우나, 쿠폰을 사용할 수 있는 인원수에 제한이 걸립니다. 만약 정해진 사용 횟수를 넘길 경우, 발급 후 미사용한 유저의 쿠폰을 회수해 주세요.
  • 한 번 진행하는 이벤트에는 여러 종류의 쿠폰이 제공될 수 있습니다. 다만, 선착순 발급 쿠폰이 여러 종류라고 하더라고 단 1개의 쿠폰만 발급받을 수 있도록 만들어 주세요.
  • 귀찮을 수 있지만, 시간이 남는다면 "중복 사용 불가능 쿠폰"과 "중복 사용 가능" 쿠폰 종류도 나눠 보세요.

프로그래밍 요구사항

  • 할인 쿠폰의 특성상, 사람들이 미친듯이 몰릴 수 있습니다. DDoS 수준의 트래픽이 몰린다고 가정하면, 어떻게 정확한 수량의 쿠폰을 발급할 수 있을까요?
  • 선착순 사용 쿠폰의 횟수가 정해진 횟수에 도달하면 미사용한 쿠폰도 회수해야 합니다. 쿠폰을 발급받은 사람들을 어떻게 트래킹할지도 생각해 봐야겠네요.

Step 5. 추천인 기능 개발

구현사항

  • 상품의 추천 링크를 만들어 봅시다.
  • 만약 어떤 사용자가 다른 사람이 발급한 링크를 타고 해당 물건을 구매할 경우, 물건 금액의 1%가 추천인에게 포인트로 들어옵니다.
  • 링크의 유효기간은 30일 (720 시간)이며, 한 링크에서 받을 수 있는 최대 포인트는 30,000 포인트로 제한됩니다.

프로그래밍 요구사항

  • 뭐, 앞쪽 Step을 겪었다면 쉽게 추론할 수 있겠지만, 포인트가 바로 땡하고 들어올 필요는 없습니다.

Step 6. 성능 테스트

구현사항

  • 실제로 개발한 서버의 성능이 어떨까요?
  • 사용자의 사용 시나리오를 설계하고, 이를 활용해 스트레스 테스트 툴을 사용한 성능 테스트를 진행해봅시다.
    • 여기서는 nGrinder를 사용해 봅시다.