온라인 식품 커머스, 상품 유형에 따라 시스템이 달라진다1P, 2P, 3P — 이 세 글자가 커머스 아키텍처를 결정한다들어가며온라인 식품 커머스를 운영하다 보면 "우리는 어떤 방식으로 상품을 팔 것인가?"라는 근본적인 질문에 부딪힌다. 이 질문에 대한 답이 바로 1P, 2P, 3P다.단순한 비즈니스 모델의 차이가 아니다. 이 선택에 따라 재고 관리 방식, 정산 시스템, 배송 프로세스, 심지어 고객 경험까지 완전히 달라진다.1. 세 가지 상품 유형1P (1st Party) — 직접 매입"내가 사서, 내가 팔고, 내가 배송한다"마켓컬리, 쿠팡 로켓배송이 대표적이다. 기업이 상품을 직접 매입하고, 자체 창고에서 재고를 관리하며, 직접 배송한다.장점품질을 직접 관리할 수 있다배송 경험을 일관되게 유지할 수 있다..
전체 글
입사 첫 주, 회사 기술 스택을 익히겠다는 마음 하나로 LINE 조세영 님의 「코틀린 코루틴의 정석」 강의를 결제했었다. 운이 좋게도 책 증정 이벤트에 당첨되어 책까지 받았지만, 정신없이 업무에 몰입하다 보니 그 책은 어느새 모니터 옆에서 먼지를 뒤집어쓴 채 있었다. 그로부터 9개월이 지난 지금, 다시 그 책을 꺼냈다. 실무에서 코루틴이 어떻게 사용되고, 어디서 도움이 되며, 어떤 함정이 있는지를 직접 코드로 체감하기 위한 목적이다. 코루틴은 단순히 비동기를 구현하기 위한 문법이 아니라, 시스템의 흐름과 동시성을 이해하기 위한 사고방식이라는 걸 실무를 통해 얕게나마 깨달았다. 그래서 이번에는 왜 이렇게 동작하는가, 서비스 코드에서는 어떻게 활용해야 하는가를 중심으로 처음부터 차근차근 정리해보려 한다. ..
"비동기로 처리하면 더 빨라요" 이 말을 백엔드 개발자라면 한 번쯤 들어봤을 것이다.하지만 진짜로 빠를까? 사실 비동기는 "더 빨라진다"보다 "기다리는 시간을 겹친다"가 더 정확한 표현이다. 이번 글에서는 동기/비동기의 개념 부터 해서 동기 코드를 어떻게 해야 성능 개선된 비동기 코드로 만들 수 있는지에 대해서 다루어 볼 것이다. 1. 동기/비동기 톺아보기 (feat . Blocking / NonBlocking)많은 개발자들이 비동기를 "동시에 여러 작업을 한다"로 이해하지만, 본질은 다르다. 비동기의 핵심은 "스레드를 붙잡고 기다리느냐(Blocking)", 혹은 "스레드를 다른 일에 돌려주느냐(NonBlocking)"에 있다.동기 : 요청을 보낸 스레드가 결과를 받을 때까지 대기-> 스레드는 아무 ..
대부분의 시스템은 초기에 단일 데이터베이스를 중심으로 모놀리식 기반 설계부터 시작된다.서비스가 분리되고 도메인 경계가 명확해지며 트래픽이 늘어날수록 각 도메인이 자신의 데이터베이스를 소유해야 하는 시점이 찾아온다. 하지만 실제로는 분리된 두 서비스가 같은 데이터베이스를 바라보는 상황이 자주 발생한다. 이 구조는 단기적으로는 편리하지만, 시간이 지날수록 결합도 증가나 장애전이, 트랜잭션 경계 혼란 등 여러 문제가 드러나게 된다.결국 분리된 서비스가 아닌 분리된 어플리케이션을 가진 모놀리식 구조처럼 된다는 것이다. (끔찍한 혼종..) 이러한 문제를 근본적으로 해결하려면, 서비스 간 통신을 데이터베이스 중심이 아닌 메시징 중심으로 분리해야 한다.즉, 인프라 아키텍처의 중심에 메시지 브로커를 두고 각 서비스가 ..
개발자 글쓰기 모임 3주차의 주제는 트랜잭션의 적용 사례와, 클린 아키텍처 적용 사례이다. 하지만 트랜잭션의 적용 사례는 2주 전에 트러블슈팅 내용으로 다루었었고, 클린아키텍처 적용 사례의 경우에는 글쓰기 모임 1주차때 작성을 했었다. https://wn1331.tistory.com/302 Coroutine과 ReactiveMongo 다중DB 환경에서 @Transactional을 사용해 보자업무를 하는 도중, 원자적으로 작업이 되어야만 하는 즉, 트랜잭션이 꼭 필요한 비즈니스 로직이 있었다.@Transactional 어노테이션을 사용해서 간편하게 트랜잭션 작업을 하고 싶은데.. 여러 블로wn1331.tistory.comhttps://wn1331.tistory.com/301 이제 와서 고쳐보는 2024년..
TDD(Test Driven Development)는 테스트 주도 개발로, 소프트웨어 개발 시 기능 구현 전에 테스트 코드를 작성하여 개발 전체적인 과정을 이끌어 가는 방법론이다. 이 접근법은 "Red(실패), Green(성공), Refactor(리팩토링)" 의 반복 사이클을 통해 코드를 작성하고 개선해 나간다. Red 단계 : 아직 기능이 구현되지 않은 상태에서 테스트를 작성하면, 당연히 실패하는 결과를 확인할 수 있다. 이 단계에서 "무엇을 구현할 것인가" 에 대한 명확한 목표가 설정된다. Green 단계 : 최소한의 코드를 작성해 테스트를 통과하게 한다. 이 때 기능이 실제로 동작하는지를 빠르게 확인 가능하다. Refactor 단계 : 기능 구현 후, 코드의 가독성과 유지보수성을 개선하기 위한 리..