Backend

RabbitMQ의 메시지 흐름은 Producer → Exchange → Binding → Queue → Consumer 순서입니다. Producer는 Exchange에 메시지를 발행하고, Exchange는 Binding 규칙에 따라 하나 이상의 Queue로 메시지를 라우팅합니다.

FastAPI는 Starlette 위에 올라가 있습니다. Starlette은 ASGI(Asynchronous Server Gateway Interface) 애플리케이션 프레임워크로, Python의 asyncio 이벤트 루프를 직접 사용합니다. Uvicorn이 새 HTTP 요청을 받으면 asyncio 이벤트 루프에 코루틴을 태스크로 등록합니다.

Spring의 @Transactional 은 AOP(Aspect-Oriented Programming) 프록시를 통해 구현됩니다. Spring 컨텍스트에서 빈을 주입받으면 실제 서비스 객체가 아니라, 그 객체를 감싼 프록시 객체를 받게 됩니다. 외부에서 @Transactional 메서드를 호출하면 프록시가 먼저 가로채고, 트랜잭션을 시작한 뒤 실제 메서드를

gRPC는 Google이 개발하고 2016년 오픈소스로 공개한 RPC(Remote Procedure Call) 프레임워크입니다. HTTP/2를 전송 계층으로, Protocol Buffers를 기본 직렬화 포맷으로 사용합니다. "gRPC Remote Procedure Calls"라는 재귀적 약어에서 이름이 왔습니다.

GraphQL을 처음 도입하면 프론트엔드 개발 속도가 빨라집니다. 필요한 필드만 요청하고, 여러 REST API를 조합하지 않아도 되고, 화면 단위 데이터 요구사항을 스키마로 표현할 수 있습니다. 문제는 서비스가 커진 뒤에 나타납니다. 단순해 보이는 쿼리 하나가 내부적으로 수백 개 resolver를 호출하고, resolver마다 데이터베이스를 따로 조회하면

Kafka를 쓰는 시스템에서 consumer lag는 가장 먼저 보는 지표입니다. 하지만 lag를 단순히 "남은 메시지 수"로만 보면 중요한 맥락을 놓칩니다. 10만 건의 lag가 있어도 초당 5만 건을 처리한다면 곧 회복됩니다. 반대로 1,000건의 lag라도 가장 오래된 메시지가 30분 전이라면 특정 파티션이나 consumer가 막혀 있을 수 있습니다.

마이크로서비스 환경에서 장애는 거의 항상 전파됩니다. 결제 서비스의 응답이 느려졌을 뿐인데 주문 API의 스레드가 대기하고, 주문 API가 느려지자 게이트웨이의 커넥션이 쌓이고, 결국 로그인이나 상품 조회처럼 결제와 직접 관련 없는 API까지 함께 느려집니다.

처음 저희가 Rust 비동기 모델을 잘못 이해한 흔적은 임베디드 스크립트 호출부에 남아 있었습니다. Node.js에서는 await 을 어디서든 호출할 수 있지만, Tokio에서는 이미 진입한 런타임 위에서 tokio::runtime::Handle::current().block on(...) 을 다시 부르는 순간 "Cannot start a runtime f

1.1 리소스 중심 설계 REST의 핵심은 리소스(Resource)입니다. URL은 리소스를 나타내고, HTTP 메서드로 행위를 표현합니다. "/users"는 사용자 컬렉션을, "/users/123"은 특정 사용자를 나타냅니다. "/getUser"나 "/createUser" 같은 동사 기반 URL은 피하세요.

1.1. 요청-응답 모델의 물리적 한계 사용자가 주문 버튼을 눌렀을 때, 주문 서버가 결제 서버를 호출하고, 결제 서버가 재고 서버를 호출하는 체인을 상상해 봅시다. 이 과정 중 하나라도 지연되면 사용자는 응답을 받지 못한 채 무한 대기에 빠집니다. 더욱 심각한 것은 결제 서버가 다운되면 전체 주문 기능이 마비된다는 점입니다.

목록 API를 만들 때 page와 size만 받으면 충분해 보입니다. 데이터가 적을 때는 offset 기반 페이지네이션이 단순하고 편합니다. 하지만 데이터가 늘고, 사용자가 무한 스크롤을 하고, 목록 중간에 새 데이터가 계속 들어오면 문제가 드러납니다.

Node.js는 I/O 중심 서비스에 강합니다. 하지만 이미지 리사이징, CSV 파싱, 암호화, 대용량 JSON 변환, 리포트 생성처럼 CPU를 오래 쓰는 작업을 요청 처리 경로에서 실행하면 이벤트 루프가 막힙니다. 한 요청의 무거운 계산이 다른 모든 요청의 응답 지연으로 번집니다.

프론트엔드와 백엔드가 독립적으로 배포되는 팀에서는 API 변경이 가장 흔한 장애 원인 중 하나입니다. 백엔드는 응답 필드를 optional로 바꿨다고 생각하지만 프론트엔드는 항상 존재한다고 가정하고, 프론트엔드는 새 query parameter를 보내기 시작했지만 백엔드는 오래된 버전에서 이를 잘못 처리할 수 있습니다.