Backend

메시지가 사라진 순간, 브로커를 탓하기 전에 설계를 봐야 한다 결제 완료 이벤트를 발행했는데 알림이 가지 않고, 재고 차감도 되지 않으며, 고객은 결제 화면에서 로딩만 보는 상황을 경험한 적이 있을 것입니다. 우리 팀이 운영하던 이커머스 플랫폼에서 배송 이벤트 처리를 RabbitMQ로 전환하고 두 달이

비동기 Python, 제대로 쓰지 않으면 오히려 더 느리다 FastAPI는 2026년 현재 Python 백엔드 생태계에서 가장 빠르게 채택되는 웹 프레임워크입니다. async def 를 라우트 핸들러에 붙이면 비동기 API가 완성된다는 인상이 있지만, 실제 프로덕션 환경에서는 그렇지 않습니다. 우리 팀이

@Transactional은 왜 예상대로 작동하지 않는가 Spring을 처음 배울 때 @Transactional 은 마법처럼 보입니다. 메서드 위에 어노테이션 하나를 붙이면 DB 작업이 원자적으로 묶인다고 배우고, 실제로 기본 케이스에서는 그렇게 동작합니다. 하지만 시스템이 커지고 서비스 계층이 복잡해질

내부 서비스 통신을 바꾼다는 것의 실제 무게 2026년 현재, 대부분의 백엔드 팀은 서비스 간 통신을 JSON over HTTP/1.1 REST로 운영합니다. 빠르게 검증하고 배포하기에는 이보다 편한 선택이 없습니다. 하지만 서비스 수가 20개를 넘어가고, 한 요청이 다섯 개 이상의 내부 서비스를 순차

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

Lag는 숫자가 아니라 사용자 지연이다 Kafka를 쓰는 시스템에서 consumer lag는 가장 먼저 보는 지표입니다. 하지만 lag를 단순히 "남은 메시지 수"로만 보면 중요한 맥락을 놓칩니다. 10만 건의 lag가 있어도 초당 5만 건을 처리한다면 곧 회복됩니다. 반대로 1,000건의 lag라도 가

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

Node.js 베테랑이 Rust로 백엔드를 옮기며 깨진 가정 7가지 저희 백엔드 팀은 5년 동안 Node.js + TypeScript 위에서 트래픽을 견뎌왔습니다. Express, Fastify, NestJS를 거치며 RPS 한계가 보일 때마다 horizontal scaling으로 버텼지만, 2025년

API(Application Programming Interface)는 소프트웨어 시스템 간의 계약입니다. 잘 설계된 API는 사용하기 쉽고, 확장하기 편하며, 오래 유지됩니다. 이 글에서는 실무에서 검증된 API 설계 원칙과 패턴들을 살펴봅니다. 1. RESTful API 설계 원칙 1.1 리소스 중심

모던 백엔드 개발에서 고도로 확장 가능하고 유연한 시스템을 구축하기 위한 핵심 패러다임은 바로 이벤트 기반 아키텍처(Event Driven Architecture, EDA) 입니다. 전통적인 요청 응답(Request Response) 방식은 직관적이지만, 대규모 분산 시스템에서는 서비스 간의 강한 결합(

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

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

통합 테스트만으로는 배포 타이밍을 막기 어렵다 프론트엔드와 백엔드가 독립적으로 배포되는 팀에서는 API 변경이 가장 흔한 장애 원인 중 하나입니다. 백엔드는 응답 필드를 optional로 바꿨다고 생각하지만 프론트엔드는 항상 존재한다고 가정하고, 프론트엔드는 새 query parameter를 보내기 시작