Distributed Application Architecture Using Queue Service

Overview

QS (Queue Service) is a fully managed message queue (queue) service that can separate and scale microservices, distributed systems, and serverless applications. In distributed systems, reliable data flow is a key factor that determines an application’s reliability and scalability. With QS, you can relay messages between producers and consumers, and use the API to store and retrieve messages in the queue to implement a latency-free processing flow. Messages processed in QS are received on a polling basis and are retained in the queue for up to 14 days. QS adopts a Point-to-Point model to ensure that a single message is processed by only one recipient, and the recipient 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 interdependency. As a result, the producer’s load or a consumer’s failure does not impact the entire system, and it ensures asynchronous, 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 above components interact as follows.

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

Use Cases

Development using Samsung Queue Service (QS) mainly focuses on lowering coupling between systems (Decoupling) and implementing reliable asynchronous communication. QS ensures stable 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 microservice 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

Traffic spikes or individual service failures also keep messages safely stored in the queue, ensuring the entire system remains stable. Independent scaling per service is possible as needed.

Background task and long-running task processing

Provide immediate response to the user while separating time-consuming tasks asynchronously.

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., VS or SCF function) polls the queue to perform image resizing, encoding, etc., in the background.

Large-scale Data Processing:

Complex analysis or report generation requests are queued and processed in the background to reduce user wait time.

Prepare for traffic surge (spike traffic handling)

Maintain system stability during sudden load increase.

When traffic spikes occur, like on large e-commerce platforms, we mitigate overload by utilizing QS’s unlimited throughput (Standard Queue) and message retention (up to 14 days). The messages are buffered in the queue, allowing consumers to process them stably.

Preliminary matters

Queue Selection

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

Standard Queue (Standard Queue)

Standard queue supports near‑unlimited message transmission. Guarantees at‑least‑once delivery. Note that, depending on the situation, messages may be sent redundantly, and there may be cases where messages are not in order. However, the standard queue aims to guarantee order as much as possible. (Best-Effort-Ordering)

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

FIFO Queue (First In First Out Queue)

FIFO queue guarantees message order. Messages are sent once, and the receiver receives only once. (Exactly-Once Processing). Duplicate messages are not allowed. However, to guarantee this arrival order, it has limited 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 perfect order.

Delivery (Delivery Method)

If the environment allows duplicate processing, Standard is efficient. If you need strict exactly-once processing, use FIFO.

Throughput (Throughput)

In high-load environments, Standard’s unlimited throughput is advantageous. FIFO is suitable for small-scale or order-centric tasks due to limitations.

Use Cases (Use Cases)

Standard is suitable for most scenarios where duplicate or order 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 not allowed, such as financial transactions and order processing.

Constraints

Please refer to the Quota service.

Considerations

KMS (Key Management Service) Encryption related

To use the KMS encryption key, the Key manager must pre-create the Master Key.

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

Using SQS in a user VPC’s workload

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

After creating the VPN PrivateLink Endpoint, please request the connection as an SR according to the user guide.

Related Services

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