Distributed Application Architecture Using Queue Service

Overview

QS (Queue Service) is a fully managed message queue (queue) service that separates and scales microservices, distributed systems, and serverless applications. In distributed systems, reliable data flow is a key factor that determines an application’s reliability and scalability. Through QS, you can relay messages between producers and consumers, and by using the API you can store and retrieve messages in the queue to implement a latency‑free processing flow. Messages processed in QS are received on a polling (Polling) basis and are retained in the queue for up to 14 days. QS adopts a point-to-point approach, ensuring that a single message is processed by only one receiver, and the receiver has full control to receive, process, and delete the message.

Architecture Diagram

If you separate the Producer and Consumer through a message queue, each component can operate independently and minimize interdependencies. As a result, the producer’s load or consumer failures do not propagate to the entire system, ensuring asynchronous and reliable task processing.

The components that make up the SQS messaging system can be broadly divided into three categories.

• Producer and Consumer (distributed application server)
• Queue (queue)
• Message

The components above interact as follows.

1. Producer creates message and sends it to Queue.
2. Queue stores message for a certain period.
3. Conumer periodically polls the queue to detect new messages, and processes them immediately once confirmed.
4. Consumer sends an acknowledgment (Ack) to the Queue after message processing is complete.
5. When Queue receives an acknowledgment (Ack) for the message ID, it removes the message from Queue.

Use Cases

Development using Samsung Queue Service (QS) mainly focuses on lowering coupling between systems (Decoupling) and implementing reliable asynchronous communication. QS ensures reliable message flow in microservice architectures or distributed systems, and can enhance the independence of producers and consumers.

Each case is a use case based on QS’s core strengths of asynchronous processing, scalability, and fault tolerance.

Asynchronous communication between microservices

The most common use case is to achieve loose coupling between services in a complex microservices environment.

Loose Coupling (Loose Coupling)

The order service does not directly depend on the payment or inventory management services, and posts messages to the QS queue. Each service polls messages from the queue and processes them independently, minimizing the impact of changes on the entire system.

Scalability and Fault Tolerance

Even during traffic spikes or individual service failures, messages are safely stored in the queue, keeping the entire system stable. Independent scaling per service is possible as needed.

Handling background tasks and long-running tasks

Provide an immediate response to the user while offloading time‑consuming tasks to asynchronous processing.

Media processing:

When a user uploads a high‑resolution image, the frontend immediately returns a success response and sends a processing task message to the QS queue.

A separate worker (e.g., a VS or SCF function) polls the queue and performs image resizing, encoding, etc., in the background.

Large-Scale Data Processing:

Queue complex analysis or report generation requests and process them in the background to reduce user wait times.

Preparing for traffic spikes (spike traffic handling)

Maintains system stability during sudden load increases.

When traffic spikes occur, as with large e-commerce platforms, use QS’s unlimited throughput (Standard Queue) and message retention (up to 14 days) to alleviate overload. Messages are buffered in the queue, enabling the consumer to process them reliably.

Prerequisites

Queue selection

QS supports Standard and FIFO queues. The characteristics of each queue are as follows.

Standard Queue (Standard Queue)

Standard queues support near‑unlimited message transmission. Guarantees at-least-once delivery (At-Least-Once-Delivery). However, depending on the situation, messages may be sent redundantly, and there may be cases where messages are out of order. However, the standard queue aims to preserve order as much as possible. (Best-Effort-Ordering)

Therefore, when developing with the standard queue, the application should be designed so that processing a message twice does not have a negative impact.

FIFO queue (First In First Out Queue)

FIFO queues guarantee message order. The message is sent once, and the recipient receives it only once. (Exactly-Once Processing). Duplicate messages are not allowed. However, to ensure this arrival order, it uses a limited number of transactions compared to the standard queue.

Queue selection considerations

Message Ordering (Message Order)

If order is essential, choose FIFO. Standard is flexible but does not guarantee a perfect order.

Delivery (delivery method)

If duplicate handling is allowed in the environment, Standard is efficient. If you need strict 1-time processing (Exactly-Once), use FIFO.

Throughput (processing)

In high-load environments, Standard’s unlimited throughput is advantageous. FIFO is suitable for small or order-focused tasks due to its constraints.

Use Cases (use cases)

Standard is suitable for most scenarios where duplicate or ordering errors can be handled at the app level. (e.g., log processing, notification system).

FIFO is suitable for sensitive environments where order and duplication are absolutely prohibited, such as financial transactions and order processing.

Constraints

Please refer to the Quota service.

Considerations

KMS (Key Management Service) encryption-related

To use KMS encryption keys, the key manager must create the master key in advance.

When using the Data Key of SCP KMS with SSE, additional SCP KMS costs are incurred depending on the reuse duration (default ***, **seconds~**minutes can be set).

Using SQS from workloads in a user VPC

To poll SQS from a Private Network, you must use the SCP VPC PrivateLink Endpoint product.

After creating the VPC PrivateLink Endpoint, please request the connection via SR according to the user guide.

Related service

This is a list of Samsung Cloud Platform services that are related to the features or configurations described in this guide. Refer to this when selecting and designing services.