https://waylog.pages.dev/category/backend Waylog Blog의 Backend 카테고리에 속한 글 모음 ko-KR Thu, 21 May 2026 13:50:29 GMT Sun, 01 Mar 2026 00:00:00 GMT Next.js https://waylog.pages.dev/posts/rabbitmq-dead-letter-retry-queue-patterns https://waylog.pages.dev/posts/rabbitmq-dead-letter-retry-queue-patterns Sun, 01 Mar 2026 00:00:00 GMT Backend 메시지가 사라진 순간, 브로커를 탓하기 전에 설계를 봐야 한다 결제 완료 이벤트를 발행했는데 알림이 가지 않고, 재고 차감도 되지 않으며, 고객은 결제 화면에서 로딩만 보는 상황을 경험한 적이 있을 것입니다. 우리 팀이 운영하던 이커머스 플랫폼에서 배송 이벤트 처리를 RabbitMQ로 전환하고 두 달이 지났을 때, 업스트림 물류 API가 30초짜리 타임아웃을 내뿜기 시작했습니다. Consumer는 메시지를 가져갔지만 처리에 실패했고, nack 설정이 없던 큐에서 메시지들은 그냥 버려졌습니다. 5, https://waylog.pages.dev/posts/fastapi-async-sqlalchemy-background-tasks https://waylog.pages.dev/posts/fastapi-async-sqlalchemy-background-tasks Mon, 19 Jan 2026 00:00:00 GMT Backend 비동기 Python, 제대로 쓰지 않으면 오히려 더 느리다 FastAPI는 2026년 현재 Python 백엔드 생태계에서 가장 빠르게 채택되는 웹 프레임워크입니다. async def를 라우트 핸들러에 붙이면 비동기 API가 완성된다는 인상이 있지만, 실제 프로덕션 환경에서는 그렇지 않습니다. 우리 팀이 일 평균 200만 건의 예약 요청을 처리하는 여행 플랫폼에서 FastAPI를 마이그레이션할 때, 잘못된 비동기 핸들러 때문에 오히려 p99 응답 시간이 40% 늘어난 적이 있습니다. 모든 라우트를 https://waylog.pages.dev/posts/spring-transaction-propagation-isolation-pitfalls https://waylog.pages.dev/posts/spring-transaction-propagation-isolation-pitfalls Sun, 11 Jan 2026 00:00:00 GMT Backend @Transactional은 왜 예상대로 작동하지 않는가 Spring을 처음 배울 때 @Transactional은 마법처럼 보입니다. 메서드 위에 어노테이션 하나를 붙이면 DB 작업이 원자적으로 묶인다고 배우고, 실제로 기본 케이스에서는 그렇게 동작합니다. 하지만 시스템이 커지고 서비스 계층이 복잡해질수록, 이 마법이 특정 조건에서 아무런 경고 없이 조용히 무효화된다는 사실을 맞닥뜨리게 됩니다. 우리 팀은 2026년 초 포인트 적립과 결제 이력을 함께 저장하는 서비스에서 정확히 이 문제를 겪었습니 https://waylog.pages.dev/posts/grpc-vs-rest-internal-service-communication https://waylog.pages.dev/posts/grpc-vs-rest-internal-service-communication Thu, 08 Jan 2026 00:00:00 GMT Backend 내부 서비스 통신을 바꾼다는 것의 실제 무게 2026년 현재, 대부분의 백엔드 팀은 서비스 간 통신을 JSON over HTTP/1.1 REST로 운영합니다. 빠르게 검증하고 배포하기에는 이보다 편한 선택이 없습니다. 하지만 서비스 수가 20개를 넘어가고, 한 요청이 다섯 개 이상의 내부 서비스를 순차 혹은 병렬로 호출하기 시작하면, 조용히 쌓이는 문제들이 있습니다. 직렬화 비용, 불명확한 타입 계약, timeout이 전파되지 않는 호출 트리, 각 서비스마다 제각각인 에러 표현 방식. 우리 팀은 https://waylog.pages.dev/posts/graphql-dataloader-n-plus-one-performance https://waylog.pages.dev/posts/graphql-dataloader-n-plus-one-performance Sat, 29 Nov 2025 00:00:00 GMT Backend GraphQL은 느린 것이 아니라 쉽게 느려진다 GraphQL을 처음 도입하면 프론트엔드 개발 속도가 빨라집니다. 필요한 필드만 요청하고, 여러 REST API를 조합하지 않아도 되고, 화면 단위 데이터 요구사항을 스키마로 표현할 수 있습니다. 문제는 서비스가 커진 뒤에 나타납니다. 단순해 보이는 쿼리 하나가 내부적으로 수백 개 resolver를 호출하고, resolver마다 데이터베이스를 따로 조회하면서 p95 latency가 갑자기 튑니다. 가장 흔한 원인은 N+1 쿼리입니다. 게시글 목록 2 https://waylog.pages.dev/posts/kafka-consumer-lag-rebalance-backpressure https://waylog.pages.dev/posts/kafka-consumer-lag-rebalance-backpressure Sun, 23 Nov 2025 00:00:00 GMT Backend Lag는 숫자가 아니라 사용자 지연이다 Kafka를 쓰는 시스템에서 consumer lag는 가장 먼저 보는 지표입니다. 하지만 lag를 단순히 "남은 메시지 수"로만 보면 중요한 맥락을 놓칩니다. 10만 건의 lag가 있어도 초당 5만 건을 처리한다면 곧 회복됩니다. 반대로 1,000건의 lag라도 가장 오래된 메시지가 30분 전이라면 특정 파티션이나 consumer가 막혀 있을 수 있습니다. 운영에서 중요한 것은 lag count, lag age, 처리량, rebalance 빈도, commit https://waylog.pages.dev/posts/api-resilience-timeout-retry-circuit-breaker https://waylog.pages.dev/posts/api-resilience-timeout-retry-circuit-breaker Mon, 13 Oct 2025 00:00:00 GMT Backend 장애는 실패한 API 하나에서 끝나지 않는다 마이크로서비스 환경에서 장애는 거의 항상 전파됩니다. 결제 서비스의 응답이 느려졌을 뿐인데 주문 API의 스레드가 대기하고, 주문 API가 느려지자 게이트웨이의 커넥션이 쌓이고, 결국 로그인이나 상품 조회처럼 결제와 직접 관련 없는 API까지 함께 느려집니다. 사용자가 보는 것은 "결제가 잠깐 느리다"가 아니라 "서비스 전체가 멈췄다"입니다. 이런 장애의 공통점은 실패를 너무 오래 붙잡는다는 것입니다. 외부 API가 10초 동안 응답하지 않는데 내부 서 https://waylog.pages.dev/posts/rust-tokio-async-backend-pitfalls https://waylog.pages.dev/posts/rust-tokio-async-backend-pitfalls Mon, 19 May 2025 00:00:00 GMT Backend Node.js 베테랑이 Rust로 백엔드를 옮기며 깨진 가정 7가지 저희 백엔드 팀은 5년 동안 Node.js + TypeScript 위에서 트래픽을 견뎌왔습니다. Express, Fastify, NestJS를 거치며 RPS 한계가 보일 때마다 horizontal scaling으로 버텼지만, 2025년 말 메인 결제 게이트웨이의 p99 latency가 320ms를 넘기면서 한계점에 도달했습니다. CPU 사용률은 여유로운데도 이벤트 루프가 막히는 전형적인 단일 스레드 한계였고, 저희는 핵심 서비스 https://waylog.pages.dev/posts/60 https://waylog.pages.dev/posts/60 Sun, 08 Dec 2024 00:00:00 GMT Backend API(Application Programming Interface)는 소프트웨어 시스템 간의 계약입니다. 잘 설계된 API는 사용하기 쉽고, 확장하기 편하며, 오래 유지됩니다. 이 글에서는 실무에서 검증된 API 설계 원칙과 패턴들을 살펴봅니다. 1. RESTful API 설계 원칙 1.1 리소스 중심 설계 REST의 핵심은 리소스(Resource)입니다. URL은 리소스를 나타내고, HTTP 메서드로 행위를 표현합니다. "/users"는 사용자 컬렉션을, "/users/123"은 특정 사용자를 https://waylog.pages.dev/posts/event-driven-architecture-ha https://waylog.pages.dev/posts/event-driven-architecture-ha Wed, 27 Nov 2024 00:00:00 GMT Backend 모던 백엔드 개발에서 고도로 확장 가능하고 유연한 시스템을 구축하기 위한 핵심 패러다임은 바로 이벤트 기반 아키텍처(Event-Driven Architecture, EDA)입니다. 전통적인 요청-응답(Request-Response) 방식은 직관적이지만, 대규모 분산 시스템에서는 서비스 간의 강한 결합(Tight Coupling)과 장애 전파(Cascading Failure)라는 치명적인 약점을 노출합니다. 본 포스트에서는 EDA의 근본적인 철학부터 고가용성 설계 패턴, 그리고 대규모 트래픽을 지탱 https://waylog.pages.dev/posts/api-pagination-cursor-offset-consistency https://waylog.pages.dev/posts/api-pagination-cursor-offset-consistency Mon, 26 Aug 2024 00:00:00 GMT Backend 페이지네이션은 목록을 자르는 문제가 아니다 목록 API를 만들 때 page와 size만 받으면 충분해 보입니다. 데이터가 적을 때는 offset 기반 페이지네이션이 단순하고 편합니다. 하지만 데이터가 늘고, 사용자가 무한 스크롤을 하고, 목록 중간에 새 데이터가 계속 들어오면 문제가 드러납니다. 같은 항목이 두 번 보이거나, 어떤 항목은 건너뛰거나, 뒤 페이지로 갈수록 쿼리가 느려집니다. 페이지네이션은 사용자 경험, 데이터 일관성, 데이터베이스 성능이 만나는 지점입니다. 단순 관리자 화면과 대규모 https://waylog.pages.dev/posts/nodejs-worker-threads-cpu-bound-tasks https://waylog.pages.dev/posts/nodejs-worker-threads-cpu-bound-tasks Mon, 05 Aug 2024 00:00:00 GMT Backend Node.js가 느린 것이 아니라 이벤트 루프가 막힌다 Node.js는 I/O 중심 서비스에 강합니다. 하지만 이미지 리사이징, CSV 파싱, 암호화, 대용량 JSON 변환, 리포트 생성처럼 CPU를 오래 쓰는 작업을 요청 처리 경로에서 실행하면 이벤트 루프가 막힙니다. 한 요청의 무거운 계산이 다른 모든 요청의 응답 지연으로 번집니다. 이벤트 루프 지연은 단순히 평균 응답 시간이 느려지는 문제가 아닙니다. health check가 늦어지고, timeout이 증가하고, websocket heart https://waylog.pages.dev/posts/backend-api-contract-testing-consumer-driven https://waylog.pages.dev/posts/backend-api-contract-testing-consumer-driven Fri, 05 Jul 2024 00:00:00 GMT Backend 통합 테스트만으로는 배포 타이밍을 막기 어렵다 프론트엔드와 백엔드가 독립적으로 배포되는 팀에서는 API 변경이 가장 흔한 장애 원인 중 하나입니다. 백엔드는 응답 필드를 optional로 바꿨다고 생각하지만 프론트엔드는 항상 존재한다고 가정하고, 프론트엔드는 새 query parameter를 보내기 시작했지만 백엔드는 오래된 버전에서 이를 잘못 처리할 수 있습니다. 스테이징 통합 테스트가 있어도 실제 배포 순서와 feature flag 조합을 모두 재현하기는 어렵습니다. API 계약 테스트는 이