Traffic to an order API increases sharply for a short period.
The order worker may slow down temporarily, but accepting orders must continue and the requests must be processed later.
Which design is most appropriate?
Place Amazon SQS between the API and workers so the queue absorbs a rate difference and separates request acceptance from asynchronous processing.
Detailed explanation
Worker delay or failure directly affects the API and does not provide loose coupling.
Worker delay or failure directly affects the API and does not provide loose coupling.
Client-only storage is not a durable server-side queue shared by workers.
Client-only storage is not a durable server-side queue shared by workers.
SQS separates acceptance from processing and retains requests when workers are temporarily slower.
SQS separates acceptance from processing and retains requests when workers are temporarily slower.
A fixed worker creates a capacity limit and cannot absorb or scale with a burst.
A fixed worker creates a capacity limit and cannot absorb or scale with a burst.
Check official documentation
Compare the following points with the official documentation.
Amazon SQSのキューイングとメッセージ保持の公式説明を確認する。
What to confirm
受付と非同期処理を分離し、急増した要求をキューで保持できる。
Key points
- Amazon SQS
- Asynchronous processing
- Loose coupling
- Queue buffering
Notes
- Environment: AWS公式SQSドキュメントの確認
- Confirm current AWS architecture guidance and service behavior in the official documentation.
Foundation review
Rate mismatch
A queue absorbs a temporary difference between arrival rate and worker rate.
Failure isolation
A worker problem need not immediately stop the API from accepting messages.