<aside> <img src="attachment:8baa7f2e-4a62-4473-83a8-59bd9b0f34e9:ChatGPT_Image_2026년_6월_12일_오후_02_02_22.png" alt="attachment:8baa7f2e-4a62-4473-83a8-59bd9b0f34e9:ChatGPT_Image_2026년_6월_12일_오후_02_02_22.png" width="40px" />

KOK

실시간 레스토랑 예약·웨이팅 플랫폼 KOK 백엔드 서비스

</aside>

📤 Kafka 기반 Choreography 이벤트 통신 구조

flowchart LR

    subgraph Producer["Event Producer"]
        RS[Reservation Service]
        WS[Waiting Service]
        RV[Review Service]
    end

    subgraph Outbox["Outbox Pattern"]
        RO[p_reservation_outbox_events]
        WO[p_waiting_outbox_events]
        RVO[p_review_outbox_events]
    end

    subgraph Kafka["Kafka"]
        RT[reservation.events.v1]
        WT[waiting.events.v1]
        RVT[review.events.v1]
    end

    subgraph Consumer["Event Consumer"]
        NS[Notification Service]
        SS[Store Service]
    end

    RS -->|예약 상태 변경| RO
    WS -->|웨이팅 상태 변경| WO
    RV -->|리뷰 생성/수정/삭제| RVO

    RO -->|Outbox Publisher| RT
    WO -->|Outbox Publisher| WT
    RVO -->|Outbox Publisher| RVT

    RT -->|예약 확정/취소/노쇼/방문| NS
    WT -->|웨이팅 등록/호출/취소/입장/미입장| NS
    RVT -->|평점 변경 이벤트| SS

    NS --> NDB[p_notifications 저장]
    NS --> SLACK[Slack 알림 발송]
    SS --> STOREDB[p_stores 평점/리뷰 수 갱신]
    SS --> REDIS[Redis 랭킹·캐시 갱신]

본 프로젝트의 Kafka 이벤트 연동은 중앙 Orchestrator가 전체 흐름을 제어하는 방식이 아니라, 각 서비스가 자신의 도메인 상태 변경 후 이벤트를 발행하고 필요한 서비스가 해당 이벤트를 구독하여 후속 작업을 수행하는 Choreography 방식으로 설계한다.

예를 들어 Reservation Service는 예약 확정·취소 이벤트를 발행하고, Waiting Service는 웨이팅 호출·취소·입장 완료 이벤트를 발행한다. Notification Service는 해당 이벤트를 구독하여 알림을 생성하고 Slack 알림을 발송한다. 이를 통해 예약·웨이팅 서비스는 알림 발송 성공 여부에 직접 의존하지 않고, 서비스 간 결합도를 낮출 수 있다.

핵심 도메인 Sequence Diagram

• 웨이팅
• 예약
• 알림

🎯 도메인별 MVP 기능 구현 현황 및 고도화 계획

• Waiting Service

• Reservation Service

• Notification Service

• Store Service

• Review Service

• User / Auth Service

• 주요 기능(발표)

🚨 도메인 별 장애 시나리오와 테스트 결과