architecture

[초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리

API는 한 번 외부에 공개되는 순간부터 "내가 마음대로 못 바꾸는 코드"가 된다. 내부 라이브러리라면 콜러를 한꺼번에 리팩터링하면 되지만, 모바일 앱·파트너사·외부 통합처럼 내가 배포 시점을 통제할 수 없는 컨슈머가 한 명이라도 있으면 이야기가 달라진다. 사용자는 앱 스토어 업데이트를 미루고, 파트너사는 분기 단위로 릴리즈를 묶고, B2B 고객은 1년 전...

[초안] CJ푸드빌 커머스/F&B 도메인 설계 면접 대비 — 슬롯 경험을 주문·결제·쿠폰·매장 상태 설계로 번역하기

CJ푸드빌 디지털 채널 백엔드 포지션은 빕스, 더플레이스, 제일제면소, 뚜레쥬르 같은 매장 운영과 모바일/웹 주문, 멤버십, 쿠폰, 예약, 키오스크가 한 도메인 안에서 맞물리는 자리다. 면접에서 검증하려는 핵심은 "F&B 커머스 도메인을 코드와 데이터로 풀어낼 수 있는가" 한 줄로 압축된다. 흔한 함정은 두 가지다. 하나는 이력서에 적힌 슬롯/예약/SaaS...

[초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드

DDD(Domain-Driven Design)는 "소프트웨어의 복잡성은 도메인 그 자체의 복잡성에서 나온다"는 전제에서 출발한다. 기술 스택을 아무리 정교하게 고르고 아키텍처 계층을 얼마나 깔끔하게 나누든, 비즈니스 규칙이 엉뚱한 곳에 흩뿌려져 있으면 결국 유지보수 비용이 폭증한다. DDD는 복잡한 도메인을 코드로 직접 표현해 변경 비용을 낮추는 데 목적이...

[초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식

--- 둘 다 "여러 개의 작은 처리 단위를 체인으로 이어서 최종 결과를 만든다"는 공통 의도를 가진다. 그래서 현장에서 자주 혼동된다. 실제로 "데코레이터를 쓴다"고 말한 코드가 책임 연쇄 구조일 때도 있고, 반대인 경우도 있다. 이 글의 목적은 두 패턴의 구조적 차이와 선택 기준을 정리하는 것이다. 한 번 정리해두면 설계 단계에서 "우리 상황은 어느 쪽...

[초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리

CJ푸드빌·F&B 계열 e-Commerce 백엔드는 단순한 "장바구니 → 결제" 흐름이 아니다. 같은 주문 한 건이 매장 픽업, 배달, 예약, 쿠폰 결합, 멤버십 적립, 프로모션 가격 정책, 결제 승인/부분취소/환불, 재고 차감, 매장 운영시간 검증까지 동시에 만족해야 한다. 도메인이 잘못 잘리면 한 가지 실패 시나리오만 발생해도 "결제는 됐는데 주문은 안...

[초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비

CJ푸드빌처럼 빕스/뚜레쥬르/제일제면소 같은 다브랜드 F&B 운영사의 디지털 채널 백엔드는 단순히 "주문 API"를 만드는 일이 아니다. 같은 회원이 어제는 매장에서 결제하고 오늘은 앱에서 픽업을 잡고 내일은 외부 배달사로 같은 메뉴를 시킨다. 가격은 매장별·시간대별로 달라지고, 쿠폰은 브랜드 단위와 멤버십 등급에 따라 중첩되며, 정산은 결제대행사·배달사·...

[초안] F&B 이커머스 결제·환불·정산 운영 가이드

F&B 이커머스(예: 빵집, 카페, 외식 브랜드의 온라인 주문/예약/선물하기/모바일 상품권)는 일반 상품 커머스와 다른 결제 운영 특성을 가진다. 단가가 작은 주문이 단시간에 폭증하고(점심·저녁 피크), 매장 단위로 정산이 분기되며, 모바일 상품권·선불충전·카카오페이 머니 같은 "현금이 아닌 결제수단"이 섞이고, 매장 사정으로 인한 부분취소가 매우 잦다....

[초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점

F&B 디지털 채널(자사앱, 키오스크, 카카오톡 채널, 배달 플랫폼)에서 주문은 단순한 CRUD가 아니다. 주문이라는 한 건의 트랜잭션은 사용자 단말, 결제 PG, 매장 POS, 주방 디스플레이(KDS), 픽업/배달 운영, 재고/할인 시스템을 가로지르는 분산 워크플로다. 이 워크플로는 거의 항상 부분 실패(partial failure), 재시도(retry)...

[초안] F&B 쿠폰·프로모션·멤버십·포인트 설계

F&B 이커머스에서 쿠폰·프로모션·멤버십·포인트는 매출 직결 도메인이면서 동시에 가장 컴플레인이 많이 나오는 영역이다. 한 번의 결제에 "신규가입 쿠폰", "브랜드 쿠폰", "매장 쿠폰", "메뉴 쿠폰", "통신사 제휴 할인", "멤버십 등급 할인", "포인트 사용"이 동시에 얹히고, 발급·사용·취소·환불이 비동기로 흐른다. 정책이 잘못 설계되면 같은 쿠폰...

[초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기

Spring 기반 백엔드 경력 중후반에서 가장 자주 마주치는 질문이 두 가지 있다. "왜 우리 서비스는 비즈니스 로직이 Controller, Service, Entity, Repository 사이에 흩어져 있어서 매번 바꾸기가 무서운가?" 그리고 "그렇다고 Hexagonal Architecture니 Clean Architecture니 하는 걸 그대로 도입하...

[초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계

모놀리식 환경에서 서비스 간 데이터 연동은 "조인 한 번이면 끝"이었다. 같은 트랜잭션, 같은 DB, 같은 JVM 안에서 데이터는 자연스럽게 일관성을 유지했다. 그러나 MSA로 넘어오는 순간 이 전제가 전부 깨진다. 상품 서비스의 상품 정보를 주문 서비스가 알아야 하고, 재고 서비스의 재고를 장바구니가 참조해야 하며, 알림 서비스는 결제 완료 이벤트를 받아...

[초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식

운영 환경의 분산 시스템은 "돌고 있는 것 같은데 느리다", "일부 사용자만 실패한다", "가끔 5xx가 튄다"처럼 이분법으로 떨어지지 않는 장애를 끊임없이 만든다. 단순한 헬스체크(Alive/Dead)로는 이 회색 지대를 설명할 수 없다. Observability(관측가능성)는 시스템의 외부 출력(logs, metrics, traces)만 보고 내부 상태...

[초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기

> 관련 문서: 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가. 이 문서는 Outbox·Inbox 한 짝의 동작 메커니즘과 transaction boundary, polling/CDC 변형, ordering 등 심화 주제에 집중하고, 위 문서는 분산 트랜잭션 맥락에서 "왜 2PC가 아닌 Outbox인가"라는 의사결정 축을 다...

[초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점

CJ푸드빌처럼 매장·키오스크·모바일 앱·웹·파트너사 연동을 동시에 운영하는 도메인에서 REST API는 여러 세대의 클라이언트가 동시에 살아 있는 상태를 전제로 한다. 백엔드는 일주일에 두세 번 배포할 수 있지만, iOS/Android 앱은 그렇지 않다. 앱스토어 심사, 사용자 강제 업데이트 동의, 구버전 OS 잔존, 사내 매장 단말의 펌웨어 라이프사이클까...

[초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴

--- 코드를 오래 작성하다 보면 반드시 만나는 장면이 있다. 결제 수단이 하나 추가될 때마다 if-else 블록이 늘어나는 PaymentService, 할인 정책 종류가 바뀔 때마다 손대야 하는 DiscountCalculator, 알림 채널이 추가될 때마다 재배포해야 하는 NotificationDispatcher. 이 구조는 처음엔 단순해 보이지만, 결국...

[초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기

F&B 커머스나 외식 프랜차이즈 주문 시스템에서 결제는 단순히 "돈이 빠져나갔다"로 끝나는 이벤트가 아니다. 한 번의 사용자 결제 시도 뒤에는 클라이언트 → 우리 서버 → PG사 → 카드사 → 다시 PG사 → 우리 서버 → 클라이언트라는 분산 호출 사슬이 존재하고, 이 사슬 어느 한 구간에서든 네트워크 타임아웃, 커넥션 끊김, 모바일 백그라운드 전환, 재시...

[초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계

대규모 커머스 백엔드는 평상시와 이벤트 시점의 트래픽 프로파일이 극단적으로 다르다. CJ 올리브영의 경우 멤버십 회원 규모가 1,600만 명을 넘고, 한 해에 수 차례 진행되는 올영세일과 같은 메가 프로모션에서는 상시 TPS의 510배가 수십 분 안에 몰린다. 이 조건에서 단순히 서버를 늘리는 것으로는 해결되지 않는다. 트래픽이 집중되는 자원(인기 상품 상...

[초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전

시니어 백엔드 면접에서 "트래픽이 평소의 10배로 튀는 상황에서 레거시 인증 모듈을 신규 모듈로 교체해야 한다. 어떻게 배포하시겠습니까?"라는 질문은 더 이상 이론 문제가 아니다. 올리브영 세일, 쿠팡 로켓배송 피크, 네이버 쇼핑 라이브 같은 국내 커머스 환경은 초당 수만 요청 단위에서 무중단 마이그레이션을 상시로 요구한다. 재배포 한 번의 rollback...

[초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략

식음료(F&B)·리테일·디지털 채널 같이 오랜 기간 운영된 서비스는 화면 한 장을 들춰보면 거의 항상 JSP/JSTL과 jQuery로 짜인 레거시 페이지가 나온다. 그 위에 모바일 앱과 SPA(React/Vue), 키오스크, 사이니지, 외부 파트너 연동, 그리고 사내 운영툴까지 겹겹이 쌓여 있다. 같은 주문/회원/쿠폰 도메인을 두고 서버 사이드 렌더링과 R...

[초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드

--- 단일 서버에 모든 기능을 몰아넣는 모놀리식 설계는 처음에는 단순하고 빠르다. 하지만 서비스가 성장하면서 네 가지 한계가 반드시 찾아온다. 첫째, 규모 확장의 비대칭성. 결제 트래픽이 폭주한다고 해서 사용자 프로필 서버까지 함께 스케일아웃 하면 비용이 낭비된다. 분산 아키텍처에서는 병목이 되는 서비스만 선택적으로 확장할 수 있다. 둘째, 배포 단위의...

[초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가

> 관련 문서: Outbox / Inbox Pattern 심화. 이 문서는 분산 트랜잭션 맥락에서 "왜 2PC가 아닌 Outbox인가"라는 의사결정 축을, 위 문서는 Outbox·Inbox 한 짝의 동작 메커니즘과 transaction boundary, polling/CDC 변형, ordering 같은 심화 주제를 다룬다. 커머스 플랫폼 백엔드에서 주문이...

[초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략

API 설계는 "잘 돌아가는 코드"와 "시스템이 되는 코드"를 가르는 경계선이다. 시니어 백엔드는 엔드포인트를 만드는 사람이 아니라, 5년 뒤에도 deprecate 비용이 작게 드는 계약(contract)을 남기는 사람이다. 특히 커머스 백엔드처럼 주문, 결제, 쿠폰, 알림이 한 트랜잭션 스토리에 묶이는 도메인은 API 한 줄의 의미를 잘못 정하면, 몇 달...

[초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure

분산 시스템에서 "실패하지 않는 서비스"는 존재하지 않는다. 우리가 만드는 모든 API는 항상 다음 네 가지 실패 모델에 노출되어 있다. - 업스트림 실패: 내가 호출하는 외부 API / 내부 마이크로서비스가 느려지거나 죽는다. p99가 평소 120ms인데 갑자기 8초로 튄다. - 다운스트림 실패: 내가 의존하는 DB, Redis, Kafka가 커넥션 한도...

[초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩

시니어 백엔드 포지션의 기술 면접에서 코딩 테스트는 "탈락시킬 사람을 거르는" 필터에 가깝고, 실제로 합격과 불합격을 가르는 단계는 시스템 설계 라운드다. 이유는 단순하다. 주니어는 주어진 API 스펙을 구현하면 되지만, 시니어는 "요구사항이 명확하지 않은 상태에서 제약 조건을 스스로 도출하고, 여러 선택지 중 트레이드오프를 명시하며 의사결정할 수 있는가"...

[초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기

CJ푸드빌 같은 외식·커머스 도메인은 표면적으로는 "메뉴 CRUD에 결제 붙이기"처럼 보이지만, 실제로는 매장 운영, 재고, 프로모션, 결제, 주문 상태 머신이 얽힌다. 이때 모든 로직을 @Service 한 클래스에 몰면 처음 6개월은 빠르지만, 1년 차부터는 결제 PG 교체, 재고 정책 변경, 주문 상태 추가가 수십 개의 if-else 가지를 수정해야 끝...

[초안] 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비

커머스/외식 도메인 백엔드에서 "주문이 두 번 들어갔다", "결제는 됐는데 접수가 안 됐다", "취소했는데 매장에는 조리 지시가 내려갔다" 같은 사고는 거의 전부 주문 상태 머신과 데이터 정합성 기본기의 문제다. 신기술이 아니라 트랜잭션, 락, 멱등성, 상태 전이 검증이 무너졌을 때 발생한다. CJ푸드빌처럼 매장 POS, 키오스크, 모바일 앱, 배달 플랫폼...

[초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구

쿠폰과 프로모션은 F&B 커머스에서 매출을 만드는 동시에 정합성 이슈가 가장 자주 터지는 영역이다. "1만 개 한정 50% 할인 쿠폰"이라는 한 줄 기획은 백엔드 입장에서 보면 동시성, 멱등성, 락 전략, 캐시 일관성, 보상 트랜잭션이 한꺼번에 등장하는 종합 문제다. 매장 오픈 이벤트, 앱 푸시 후 1분, 신메뉴 런칭 같은 짧고 강한 트래픽 스파이크에서 한...

[초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴

템플릿 메서드 패턴은 GoF 책에서 가장 먼저 배우는 행위 패턴 중 하나이고, 거의 모든 백엔드 프레임워크 깊은 곳에 박혀 있다. Spring의 JdbcTemplate, RestTemplate, TransactionTemplate, AbstractApplicationContext.refresh(), Spring Batch의 Tasklet/ItemReader...

디자인 패턴

소프트웨어 설계 과정에서 반복적으로 발생하는 문제들에 대해 검증된 해결책을 정형화한 모범 사례라고 정의할 수 있다. 이 문서는 아키텍처/설계 패턴의 가벼운 허브 문서다. 각 패턴의 핵심 개념만 빠르게 훑고, 자세한 학습은 개별 상세 문서로 이어지도록 구성한다. - 전략 패턴 상세 문서 - 런타임에 알고리즘을 교체하는 구조, 분기문 제거, OCP/테스트...

분산 트랜잭션

분산 트랜잭션은 두 개 이상의 네트워크로 연결된 시스템(데이터베이스, 메시지 큐 등)에 걸쳐 있는 트랜잭션을 의미한다. 핵심은 원자성을 보장하는 것이다. 즉, 모든 서비스의 작업이 성공하거나, 하나라도 실패하면 모두 이전 상태로 되돌려야 한다. - 가장 전통적인 방법으로, 트랜잭션 조정자(Coordinator)가 모든 참여 서비스에 '준비'를 시키고, 모두...

캐시 설계 전략 총정리

캐싱은 RAM 기반의 빠른 저장소를 활용해 DB 부하를 줄이고 응답 속도를 높이는 기술이다. RAM은 DB보다 수십수백 배 빠르지만 용량이 제한적이기 때문에 어떤 데이터를 어떻게 저장하고 갱신할지에 대한 전략이 필요하다. 기본 용어: - Cache Hit: 캐시에 데이터가 있어 바로 반환 (빠름) - Cache Miss: 캐시에 없어 DB에서 조회 후 캐시...