분산 시스템을 처음 설계할 때 가장 흔하게 마주치는 함정은 "API가 동기적으로 다른 API를 호출하면 된다"는 단순함의 유혹이다. 주문 API가 결제 API를 부르고, 결제 API가 재고 API를 부르고, 재고 API가 배송 API를 부른다. 코드는 깔끔하지만 결제 API가 100ms 느려지는 순간 주문 API의 응답 시간도 100ms 늘어나고, 재고 API가 다운되면 주문 자체가 안 받아진다. 시간적·공간적 결합(temporal/spatial coupling)이 시스템 전체의 가용성을 곱셈으로 떨어뜨린다.
메시지 큐는 이 곱셈을 덧셈으로 바꾸기 위한 가장 오래된 도구다. 1980년대 IBM MQSeries부터 1990년대 RabbitMQ의 전신인 AMQP 표준, 2000년대 ActiveMQ를 거쳐 2006년 7월 AWS가 EC2와 S3보다 먼저 출시한 첫 번째 서비스 중 하나가 바로 **SQS(Simple Queue Service)**다. 이 글에서는 SQS가 어떤 분산 시스템 트레이드오프를 명시적으로 선택했는지, 그리고 그 선택이 시험과 실무 양쪽에서 어떤 시나리오를 만드는지를 본다.
SQS는 표준(Standard)과 FIFO 두 가지 큐 타입을 제공하는데, 이 둘의 차이는 단순한 "옵션 두 개"가 아니라 분산 시스템 이론에서 가장 유명한 trade-off의 양 끝단을 그대로 노출한 결과다