서로 다른 작업을 함께 처리하는 파이프라인 설계 기록

이 시리즈가 검증하려는 것

처리량을 높이는 일보다 먼저, 성격이 다른 실패가 서로 전파되지 않게 만듭니다. 각 글은 작업의 상태 전이, queue·session·idempotency 경계, 실패 주입 결과와 아직 보장하지 못하는 범위를 실제 코드와 운영 제약에 연결합니다.

1. 1편 · Queue isolation 발행

   큐가 가득 찼을 때 작업을 잃지 않으려면

   실제 queue-full 거절과 stale recovery를 바탕으로, bounded backlog·publisher confirm·재예약을 하나의 과부하 계약으로 연결합니다.

2. 2편 · Session ownership 발행

   세션을 잃지 않으려면 요청을 어디로 보내야 하는가

   계정별 affinity로 기존 세션이 있는 인스턴스로 보내고, 모든 세션 작업을 같은 account lock으로 직렬화합니다.

3. 3편 · Browser capacity 발행

   브라우저 worker는 CPU worker도 I/O worker도 아니었다

   Node, browser process, page lifecycle, proxy와 host 자원이 함께 만드는 용량 경계를 다룹니다.

4. 4편 · Message semantics 운영 근거 정리 후

   메시지가 두 번 오면 무엇을 한 번만 처리할 것인가

   at-least-once 전달에서 외부 쓰기 중복과 완료 결과의 정합성을 어떤 계약으로 다룰지 정리합니다.

5. 5편 · Hybrid operations 집필 예정

   ECS와 물리 서버가 공존할 때 배포는 라우팅 정합성 문제가 됐다

   blue/green, DNS, Traefik과 endpoint drift를 호출 경로 전체의 운영 계약으로 다시 정의합니다.