TIL - MSA에서 HTTP vs Kafka, Spring Cloud Gateway

면접 질문

"대용량 트래픽인데 왜 Gateway에서 Kafka를 사용하지 않고 HTTP로 서비스 간 통신을 했나요?"

처음에는 "대용량 = Kafka"라고 생각해서 제대로 답하지 못했다.

하지만 질문의 의도는 Kafka를 써야 하는 상황과 HTTP를 써야 하는 상황을 구분할 수 있는지를 확인하는 것이었다.

---

내가 구현했던 구조

Client
    │
HTTPS
    ▼
Spring Cloud Gateway
    │
HTTP
    ▼
User Service
    │
HTTP
    ▼
Wallet Service

 

기존에는

Gateway
   │
HTTP
   ▼
User Service
   │
userId 조회

 

와 같이 Gateway가 User Service를 호출하여 userId를 조회했다.

이를 개선하면서

• JWT Token에 userId를 포함
• Gateway가 User Service를 호출하지 않도록 변경

하여 서비스 호출을 하나 줄였다.

즉,

HTTP 자체를 개선한 것이 아니라 불필요한 HTTP 호출을 제거하여 동기 호출 비용을 줄인 것이다.

---

•  

이후 받은 면접 질문

"그렇게 개선했더라도 왜 Gateway에서 Coupon Service로는 Kafka(또는 Queue)를 사용하지 않았나요?"

처음에는 질문의 의도를 제대로 이해하지 못했다.

면접관이 궁금했던 것은

"대용량 트래픽에서 Queue(Kafka/RabbitMQ)를 이용해 병목을 완화하는 구조를 고려해본 적이 있는가?"

였다.

즉,

HTTP냐 Kafka냐의 문제가 아니라,

대량의 요청을 Queue에 적재(Buffering)하여 순간적인 트래픽을 흡수하는 아키텍처를 경험했는지를 확인하려는 질문이었다.

---

내가 답했으면 좋았을 내용

쿠폰 선착순 발급은

• 사용자가 즉시 성공/실패를 알아야 하는 API
• Request-Response가 필요한 동기 처리

이므로 Gateway → Coupon Service 구간은 HTTP를 선택했다.

또한 Spring Cloud Gateway는

• Spring WebFlux
• Netty(Event Loop)
• 비동기/논블로킹

기반이므로 HTTP 요청도 높은 동시성으로 처리할 수 있다.

반면 Kafka는

• 즉시 응답이 필요 없는 작업
• 또는 Queue를 이용해 순간적인 트래픽을 흡수하고 후속 처리하는 구조

에 적합하다.

따라서 당시 구조에서는 HTTP를 선택했지만,

트래픽 규모나 요구사항에 따라

• Queue를 이용한 버퍼링
• 비동기 처리
• 후처리 분리

등도 충분히 고려할 수 있는 아키텍처라고 답했으면 더 좋았을 것이다.

---

💡 이번 면접에서 얻은 인사이트

이번 질문을 통해 느낀 점은,

면접관은 단순히 "Kafka를 써봤냐"를 묻는 것이 아니라,

"HTTP와 Queue를 언제 선택하고, 병목을 줄이기 위해 어떤 아키텍처를 적용할 수 있는지"

를 확인하고 있었다는 것이다.

즉, 기술 자체보다 아키텍처적인 사고 과정을 보고 있었던 질문이었다.

 

 

추가로 알게 된 점

처음에는

"사용자가 즉시 성공/실패를 알아야 하므로 Kafka는 사용할 수 없다."

고 생각했다.

하지만 공부해보니 이것도 절반만 맞는 말이었다.

Kafka를 사용하더라도 사용자 입장에서는 거의 동일한 UX를 제공할 수 있다.

예를 들어,

Client
    │
HTTP
    ▼
Gateway
    │
Kafka
    ▼
Coupon Consumer
    │
쿠폰 발급 처리
    ▼
결과 저장
    │
SSE / WebSocket / Polling
    ▼
Client

 

와 같은 구조도 가능하다.

즉,

• 사용자는 버튼을 누른다.
• 서버는 요청을 Queue에 적재한다.
• Consumer가 쿠폰 발급을 처리한다.
• 최종 성공/실패를 SSE, WebSocket, Polling 등을 통해 사용자에게 전달한다.

UX는

발급 중...
↓

발급 성공

 

처럼 HTTP 동기 처리와 거의 동일하게 만들 수 있다.

---

HTTP와 Kafka의 차이

핵심은

"사용자 경험(UX)" 이 아니라

"시스템 내부 처리 방식" 이다.

HTTP는

• Request-Response
• 즉시 처리
• 구조가 단순하다.

Kafka는

• Queue(Buffer)를 이용하여 순간적인 트래픽을 흡수할 수 있다.
• Consumer 수를 조절하여 처리량을 제어할 수 있다.
• 병목을 완화하고 서비스 간 결합도를 낮출 수 있다.

즉,

HTTP는 사용자와의 통신 방식이고, Kafka는 내부 처리 방식을 변경하는 선택지인 것이다.

---

최종적으로 이해한 점

이번 질문에서 면접관은

"왜 Kafka를 안 썼냐?"

를 물은 것이 아니라

"트래픽이 폭주하는 상황에서 Queue를 이용한 버퍼링과 비동기 처리 구조도 고려해봤는가?"

를 확인하고 싶었던 것 같다.

또한 Spring Cloud Gateway는 WebFlux + Netty(Event Loop) 기반이므로 HTTP 요청도 논블로킹으로 높은 동시성을 처리할 수 있다.

즉,

• Gateway의 동시 요청 처리(WebFlux + Netty)
• 서비스 내부의 병목 완화(Kafka/RabbitMQ)

는 서로 다른 문제이며,

두 기술은 경쟁 관계가 아니라 함께 사용할 수 있는 아키텍처 요소라는 점을 이해하게 되었다.