흐름의 방향을 강물에 빗댄 말이다. 다만 무엇의 흐름을 기준으로 하느냐에 따라 방향이 반대로 쓰인다. 서비스 간 호출을 말할 때는 요청이 흘러가는 쪽을 기준으로 다운스트림 = 내가 호출하는 쪽, 업스트림 = 나를 호출하는 쪽이라 부르는 경우가 많다. 아래 설명은 이 용법을 따른다.
브라우저 ──▶ BFF ──▶ 상품·주문 서버 ──▶ DB
(업스트림) (나) (다운스트림)- 기준은 항상 "나"다. 브라우저에게는 BFF(Backend For Frontend)가 다운스트림이고, BFF에게는 뒤의 상품 서버가 다운스트림이다
- "다운"은 등급이 낮다는 뜻이 아니다. 오히려 DB처럼 핵심 시스템이 다운스트림인 경우가 많다
자주 쓰이는 맥락
- 장애 전파: 다운스트림 하나가 느려지면 그걸 기다리는 업스트림들이 줄줄이 막힌다. 그래서 타임아웃, 재시도 제한, 서킷 브레이커(circuit breaker)를 다운스트림 호출마다 둔다
- 설정 오류: "다운스트림 URL이 잘못 박혀 503"이라는 말은 내가 호출할 뒤쪽 서버 주소를 못 찾았다는 뜻이다. 컨테이너 환경에서는 호스트 이름이 도커 DNS로 풀리는지부터 본다
- 지연 실패: 다운스트림이 아직 안 떠 있어도 나 자신은 정상 부팅할 수 있다. 실제로 그쪽을 호출하는 순간에만 실패한다. 그래서 서비스를 단계별로 띄울 수 있다
반대 방향 용법
프록시·HTTP 쪽은 응답(데이터)이 흘러오는 쪽을 기준으로 삼아, 내가 요청을 넘기는 뒤쪽 서버를 업스트림이라 부른다. nginx의 upstream 블록(nginx로 SPA 배포)과 Envoy의 upstream·downstream이 이 용법이고, HTTP 명세(RFC 9110)도 "메시지는 업스트림에서 다운스트림으로 흐른다"고 정의한다. Git에서 내 포크가 따라가는 원본 저장소를 upstream이라 부르는 것도 같은 결이다. 그래서 문서나 대화에서 이 말이 나오면 어느 쪽 기준인지 먼저 확인하는 편이 안전하다.
서비스 경계를 어디에 긋느냐는 조직 구조를 닮는다는 콘웨이의 법칙와, 브라우저 요청과 서버 간 요청의 차이는 브라우저 요청과 서버 간 요청를 본다.