확장 가능한 이커머스 데이터 모델 구축

시작하기에 앞서

Fabric이라는 서비스에서 운영하는 블로그 글로 이커머스 데이터 모델을 구축할 때 생각해볼 만한 내용이라 허락받고 번역합니다. 기본적으로 API-first 서비스를 사용하는 것이 생산성에 유리하다는 논조이며 원글 말미에는 관련 서비스 홍보도 포함되어 있습니다.

이커머스 데이터 모델

온라인 제품 판매가 비즈니스의 핵심적인 부분이라면 확장할 수 있고 유연하며 빠른 이커머스 데이터 모델을 구축해야 합니다. Shopify나 BigCommerce와 같은 대부분의 기존 공급 업체들은 매월 몇백만 달러의 주문을 판매하는 소규모 스토어를 위해 만들어졌기 때문에, (대) 규모로 운영하는 수많은 이커머스 소매 업체들은 맞춤형 솔루션을 만들기 위해 조사(연구)를 시작하곤 합니다.

이 글에서는 이러한 인프라 구축을 시작하는 데 필요한 사항을 살펴봅니다. 고려해야 할 부분은 무엇인가요? 데이터 모델은 어떻게 생겼나요? 얼마나 많은 작업이 서로 관련되나요?

그 과정에서 대안을 찾아보겠습니다: 제품 카탈로그, 가격 책정과 주문 전반에 걸쳐 데이터를 관리하는 API 기반 커머스 플랫폼은 모놀리스에 얽매이지 않고, 플랫폼을 다시 만들 필요도 없게 해줍니다.

참고: 이커머스 데이터 모델의 전체 요약 다이어그램은 글 끝에 있습니다.

고객은 누구입니까?

먼저 이커머스 애플리케이션에서 아이템을 구매할 사람을 고려해야 합니다. 그 결과로 데이터베이스에 고객 정보를 어떻게 모델링 할 수 있나요? 여러분은 고객 이름, 이메일 주소 등과 같은 기본 정보를 알고 싶을 것입니다. 고객이 시스템에서 프로필을 생성할 수 있기를 원하는 건가요? 아니면 고객이 구매할 때마다 매번 양식을 작성하기를 원하는 건가요?

시작하기 전에 기본 모델은 다음과 같습니다:

고객이 영구적인 프로필을 가지기 원한다면 그들이 애플리케이션에 로그인을 할 수 있는 방법을 구축해야합니다. 더 많은 실제 요구사항을 고려하여 여러분은 로그인 시도 기록과 패스워드 기록 추적을 원할수도 있습니다.

고객이 대규모 조직의 일부인지 여부를 고려할 수도 있습니다. 그렇다면 패스워드 재설정을 어떻게 처리할까요? Single Sign-On(SSO) 또는 OAuth 지원이 필요한가요?

깊이 있게 들어가기: Addresses

지금까지 보인 데이터 모델에서 고객과 연결된 주소가 없다는 것을 알아차렸나요? 이 모델의 한 부분으로 고객 주소를 포함하는 것이 처음일 수 있습니다. 그러나 대부분의 고객은 청구나 배송지와 같은 여러 주소와 여러 종류의 주소를 갖게 될 것입니다. 또한 B2B 소매 업체는 그들이 지원하는 창고와 사무실의 수에 따라 여러 배송 위치를 고려해야 할 수도 있습니다.

만약 청구나 배송지 주소가 다르면 어떤 일이 생기나요? 아마, Customer 테이블에 칼럼을 추가하는 것 이상을 해야 합니다! 그렇게 간단하지 않습니다.

그럼 청구서 주소를 저장하는 것이 애플리케이션의 확장성에 어떤 영향을 미치나요?

결제와 배송 지역을 각각 자체 데이터베이스를 가지는 별도의 (마이크로)서비스로 분리하면 청구와 결제 주소를 Customer영역에 넣는 것이 “chatty” 서비스로 이어집니다. 이것은 마이크로 서비스를 구축할 때 잘 알려진 디자인 악취입니다.

이 이슈를 방지하기 위해, 주소를 필요로 하는 적절한 영역/서비스 내에 주소를 두는 것이 좋지만 데이터 모델이 더 복잡해집니다.

이러한 복잡성을 피하는 한 가지 방법은 API-first 소프트웨어 제공 업체의 주문 관리 시스템 (OMS)을 고려하는 것입니다. 이 소프트웨어를 사용하면 몇 달의 엔지니어링 시간을 소비하지 않고도 OMS를 데이터 모델에 통합 할 수 있습니다.

어떻게 제품과 카탈로그를 구성합니까?

스토어에 들어갈 때 (직접 또는 디지털 방식으로) 가장 먼저 보게 되는 것은 바로 구매할 수 있는 제품이며, 일반적으로 여러분이 쇼핑할 것 같은 몇 가지 고려 사항이 표시됩니다.

이커머스 웹 애플리케이션 경우 다음과 같은 사항들을 강조하고 싶을 것입니다:

• 베스트셀러 제품
• 인기 제품
• 신제품
• 검색 기준에 따라 제품을 검색하는 기능

고객에게 해당 정보를 제공하려면 먼저 제품에 대한 가격, 구매 내역 데이터 등 많은 데이터를 추적해야 합니다.

제품 카탈로그에 대한 데이터 모델을 만드는 “첫 번째 사례”를 살펴 보겠습니다:

위는 제품 이름, SKU(재고 관리 코드)와 가격 같은 몇 가지 기본 정보를 가진 Product 테이블입니다. 또한 제품과 관련된 다양한 카테고리를 나타내는 다른 테이블에도 연결됩니다. 그리고 사이트 방문자가 다양한 제품을 효율적으로 검색 할 수 있도록 인덱스 및 풀 텍스트 검색을 Product 테이블에 전략적으로 추가할 수도 있습니다.

이것은 적절한 첫 번째 시도입니다. 그러나, 보다 현실적이고 유용한 이커머스 제품 카탈로그를 얻으려면 다음과 같은 더 많은 요구 사항을 지원해야 합니다.

• 사이트 관리자가 제품 가격 동향을 분석 할 수 있도록 가격 내역 추적
• 제품 페이지에 표시할 관련 제품 지원
• 고객이 개별 공급 업체/회사에서 판매하는 모든 제품을 볼 수 있도록 제품 공급 업체 통합

이와 같은 추가 요구 사항을 처리하기 위해 다음 데이터 모델을 사용할 수 있습니다:

이 모델은 가격을 제품 자체에 포함하므로 아직 완벽하진 않습니다만, 적어도 이전 가격 내역을 유지할 수 있습니다.

또 다른 옵션은 가격 책정을 처리하는 API-first 소프트웨어 제공 업체의 가격 및 프로모션 엔진과 이커머스 스토어를 통합하는 것입니다. 이렇게 한다면, 위치, 장바구니 또는 주문 내역에 따라 다른 사용자에게 다른 가격을 적용 할 수 있습니다.

깊이 있게 들어가기: Pricing

위의 더 복잡한 제품 데이터 모델은 여전히 같은 테이블에 제품 가격을 가지고 있지만, 실제 대규모 애플리케이션에서는 아마 최선의 방법이 아닐 수 있습니다.

조직에 재고/창고, 영업, 마케팅, 고객 지원 등과 같은 다양한 부서가 있다고 가정합시다. 판매자는 제품의 판매 가격을 결정하는 전문가이기 때문에 아이템의 가격을 변경할 수 있는 전용 시스템이 있을 수 있습니다. 고객의 청구와 배송지 주소에 대한 고려 사항과 마찬가지로, 핵심 Product 테이블에 가격을 남겨두면 크로스 바운더리/서비스 통신이 이어질 수 있습니다.

그러므로, 영업 부서가 가진 데이터 자장소 아래에 제품 가격을 저장할 수 있습니다. 그러나 잊어서는 안될게 아직 고려하지 않은 다음과 같은 다른 많은 종류의 “가격”이 있습니다:

• 공급 업체로부터 재고 구매할 시 가격 (비용)
• 고객 판매 가격
• 할인 된 판매 가격
• 제조업체 권장 소매가

이러한 모든 것을 조직 구조의 맥락에서 처리하려면 데이터 모델에서 훨씬 더 많은 탐색과 복잡성이 요구됩니다. 엔지니어링 팀에서 이 작업을 수행할 수 있지만 시간이 오래 걸립니다. 기존 업체가 서비스하는 솔루션을 사용하면 이커머스 데이터 모델링 일정을 몇 주나 몇 개월을 줄일 수 있습니다.

어떻게 주문을 간소화합니까?

이제 데이터베이스에 고객이 있고 구매할 수 있음으로, 주문 처리 프로세스와 데이터 모델을 설계하는 방법에 대해 생각해야 합니다.

주문 과정은 다음과 같습니다:

1. 고객이 제품을 검색하는 동안 장바구니에 제품을 넣습니다.
2. 고객이 장바구니에 있는 제품을 구매하기로 결정합니다.
3. 고객이 주문 구매를 진행합니다.
4. 고객은 이메일 영수증 또는 주문 확인 번호를 받습니다.

하지만 이렇게 간단한 경우는 드뭅니다. 유동적인 점이 많기에 주문을 하는 것이 매우 까다로울 수 있습니다:

• 제품
• 활성화하는 카트
• 장바구니가 주문으로 전환됨
• 고객 확인이 있는 최종 주문

주문 배치에 대한 간단한 데이터 모델을 살펴본다면 다음과 같을 수 있습니다:

ShoppingCartItem 테이블의 각 row에는 제품의 “캡처된” 가격이 포함됩니다. 고객이 장바구니에 아이템을 넣을 때 그때 당시 가격으로 “고정” 상태가 유지되어야 하나요? 만약 그렇다면, 얼마나 오래 유지되어야 하나요?

참고: 가격 기능은 앞서 “깊이 있게 들어가기: Pricing” 섹션에서 언급 한 대로 제품 소유자와 논의해야 하는 비즈니스 요구 사항입니다.

미납 주문에도 같은 질문이 적용됩니다. 만약 고객이 할인된 아이템을 주문했다면, 지불하기 전까지 할인된 가격을 영원히 유지해야 하나요? 아니면 만료되나요?

주문 데이터 모델에 대해 고려해야 할 다른 질문은 다음과 같습니다:

• 주문들에 대한 분석을 추적하고 있나요?
• 고객이 결함이 있는 아이템을 반품하면 어떤 일이 일어나나요?
• 동일한 데이터 모델 내에서 배송 처리를 해야 하나요? 아니면 전용 배송 컨텍스트/스키마가 있어야 하나요?

이런 몇 가지 우려 사항을 염두에 두고 다음과 같은 데이터 모델을 만들 수 있습니다:

이보다 복잡한 주문 모델에서 유의해야 할 몇 가지 사항은 다음과 같습니다:

• ShoppingCartItem은 이제 고정된 가격에 대한 만료 날짜를 지원합니다.
• ShoppingCartHistory는 아이템이 추가, 제거 등이 될 시 추적합니다.
• 주문된 아이템이 반품 될 수 있습니다 (이것은 같은 제품의 X 아이템 중 1개가 반품되는 경우는 여전히 처리되지 않습니다).
• 한 주문은 여러 개의 배송이 있을 수 있습니다 (예, Amazon이 주문을 여러 패키지/배송으로 나누는 방법).

이 글은 또한 JSON 문서나 이벤트 소싱과 같은 대체 데이터 저장 방법을 사용한 것도 다루지 않았습니다!

결론

어떻게 모든 조각이 연결되어 맞는지 보는 데 도움이 되도록, 여기에 모든 다이어그램을 함께 표시했습니다. 그리고 가독성을 높이기 위해 Customer 테이블에 대한 여러 링크/라인들을 제거했습니다.

위에서 언급했듯이, 이 글에서는 결제 처리와 인보이스 같은 많은 기본 사항도 다루지 않습니다. 여기에 포함된 기능 외에도, 결국 다음과 같은 더 고급 기능이 필요할 수 있습니다:

• 쿠폰 코드
• 세금
• OAuth 공급자, 다른 소매 업체 또는 파트너와의 타사 통합
• 배송 추적 알림

이커머스 애플리케이션을 위한 데이터 모델을 구축하는 것은 보았듯이 쉽지 않습니다. 간단한 데이터베이스 테이블 세트로 보이는 것은 일단 실제 요구 사항을 살펴보면 그리 간단하지 않습니다.

다른 방법 (Fabric)

만약 이런 능력을 바로 가지고 사용할 수 있다면 어떨까요?

Fabric은 고객, 주문 및 배송 관리와 같이 이 글에서 얘기한 모든 작업을 하는 데 도움이 되는 올인원 커머스 플랫폼입니다. 가장 중요한 것은 마이크로 서비스 기반의 API-first 플랫폼입니다. 즉, 필요한 서비스를 선택하고 다른 내부 또는 외부 서비스와 원활하게 통합할 수 있습니다.

high level에서 Fabric 플랫폼에는 다음 기능들이 포함됩니다:

• 고객, 주문 등을 관리하는 데 도움이 되는 완전한 이커머스 APIs
• 기존 SKU를 대량 로드하는 데 도움이 되는 툴들
• 고객 행동을 사용하여 맞춤형 프로모션 및 가격을 제공하는 분석 툴
• 재고 이행을 예측과 결제 처리를 자동화하는 데 도움이 되는 주문 관리 툴
• 그리고 더!

이러한 기능이 이커머스 애플리케이션에 필요한 것처럼 들리면 Fabric을 확인하세요.

출처

Building a Scalable E-Commerce Data Model