Java 17 · Spring Boot 3.2
JPA와 REST API를 중심으로 기능별 도메인과 서비스 로직을 구성했습니다.
BACKEND SERVER
와우배달
Project summary
음식점·고객·라이더를 잇고,
주문부터 배차까지 이어지는 배달 API
System flow요청이 배달 데이터로 이어지는 구조
01
Client
고객·음식점·라이더 요청
02
NLB · ALB
외부 트래픽 전달과 분산
03
Spring Boot
주문·결제·배차 로직 처리
04
MySQL
서비스의 주요 데이터 저장
05
Redis
세션과 반복 조회 캐시
06
Kafka
서비스 이벤트 전달
Overview
프로젝트 개요
배달 서비스의 핵심 흐름을 서버 관점에서 직접 설계했습니다.
회원과 음식점, 메뉴, 주문, 결제, 라이더 배차를 하나의 REST API로 연결한 개인 백엔드 프로젝트입니다. 기능 구현뿐 아니라 동시 요청과 피크 시간대의 부하, 배포 구조까지 함께 고민했습니다.
- Role
- 백엔드 설계 · API 개발 · 테스트 · 배포 구성
- Service
- 음식점 · 고객 · 라이더 중개
- Core
- 주문 · 결제 · 배차 · 알림
- Type
- 개인 프로젝트
Key decisions
중요하게 본 것
기능의 개수보다 실제 배달 흐름에서 문제가 될 지점을 먼저 봤습니다.
- 01
가까운 음식점을 빠르게 찾기
위치 정보를 단순 거리 계산으로 반복 조회하지 않고, S2 기반 공간 인덱스를 활용해 주변 음식점 검색 구조를 잡았습니다.
- 02
같은 배차에 요청이 몰리는 상황 다루기
여러 라이더가 동시에 한 주문을 잡으려 할 때 한 명만 배정되도록 동시 요청을 고려한 배차 흐름을 설계했습니다.
- 03
자주 읽는 데이터는 가볍게 제공하기
피크 시간대의 반복 조회를 줄이기 위해 Redis 캐시와 세션을 사용하고, Kafka로 이벤트가 이어질 수 있는 구성을 마련했습니다.
System flow
요청이 배달 데이터로 이어지는 구조
외부 요청을 애플리케이션으로 전달하고, 성격에 따라 저장·캐시·이벤트 영역으로 나눴습니다.
01Client
고객·음식점·라이더 요청
02NLB · ALB
외부 트래픽 전달과 분산
03Spring Boot
주문·결제·배차 로직 처리
04MySQL
서비스의 주요 데이터 저장
05Redis
세션과 반복 조회 캐시
06Kafka
서비스 이벤트 전달
README에 정리된 비용 중심의 AWS 구성을 기준으로 표현했습니다. 관리형 서비스로 전환할 수 있는 다음 단계도 함께 검토했습니다.
Stack
사용한 기술
MySQL · Redis · Kafka
영구 저장, 세션·캐시, 이벤트 처리를 역할별로 나눴습니다.
JUnit · Mockito
외부 API와 분리된 서비스 단위 테스트로 주요 기능을 확인했습니다.
Docker · AWS · Jenkins
컨테이너 기반 실행 환경과 CI 배포 구조를 구성했습니다.
Outcome
만든 결과
14테스트 파일
S2위치 기반 음식점 검색
3MySQL · Redis · Kafka 데이터 영역
회원가입부터 음식점 조회, 주문과 결제, 라이더 배차까지 배달 서비스의 주요 흐름을 API로 구현했습니다. 기능별 서비스 테스트를 더해 변경 시 핵심 로직을 다시 확인할 수 있게 했습니다.
실사용 트래픽이나 성능 수치는 아직 측정하지 않아 포트폴리오에는 구현 범위와 검증 가능한 구조만 담았습니다.