Data is everywhere in garment factories,
but time is always short

“Real-time production data from a factory in Vietnam… v
iewable instantly from headquarters in Korea?”

Most people are skeptical when they hear that.
Thousands of kilometers away, thousands of devices,
data pouring in every minute…
Is it really possible?

At SIJE, we’ve made it possible.

Thousands of IoT devices—called Monolog—installed
at a large-scale garment factory in Vietnam transmit data wirelessly:
production status, machine conditions, error codes, and more.

That data is processed and made viewable, almost in real time,
via an AWS-based website for the Korean headquarters.

This isn’t just about attaching a few devices.
It’s the result of a full-stack system design
—from on-site network architecture
to cloud infrastructure, API response flows, and UX optimization.

A System Map for Smart Sewing

Here’s how the data flows through the system we built:

Key Features of This Flow:

• Flexible queue-based architecture using SQS, without relying on IoT Core or MQTT
• Data is consumed directly by ECS and stored in DocumentDB
• The client requests near real-time data via a React web app
• All IoT devices are connected wirelessly via Wi-Fi

Garment Factory IoT: Connecting IoT Devices to Sewing Lines

Thousands of Monolog devices are connected to the network
via Wi-Fi in each factory.
These devices transmit sensor data every 1–2 minutes.

Characteristics of the Data:

• Includes operation status, production count, temperature, error codes, etc.
• Small in size but high in frequency, and transmitted concurrently by many devices

Local Gateway: The Middle Manager of Sewing Data

All data doesn’t go straight to the cloud.
It first gathers at an on-site Local Gateway Server in the factory.

This isn’t just a simple repeater. The gateway:

• Pre-processes data
• Eliminates duplicates
• Sends it in batches to SQS

Each factory has at least two local gateways for high availability (HA).

Resilient to Data Surges with an SQS-ECS Architecture

Once the local gateway sends the data, it enters AWS SQS
—and from here, cloud processing begins.

Why we chose SQS:

• It safely absorbs surges in data via queueing
• Failed messages go to a Dead Letter Queue (DLQ)
• Flexible handling of message order and duplication

This queue is handled by a NestJS container app running on an ECS cluster.

ECS Containers: The Workforce Moving Garment Data to the Cloud

• Receives messages from SQS in batches
• Parses JSON and normalizes the data
• Stores raw data in DocumentDB (MongoDB-compatible)
• Archives raw data long-term in S3

ECS container count scales automatically with the SQS queue length.
Even if there’s a flood of incoming data, ECS scales to handle it.

DocumentDB: The Hub for Real-Time Sewing Data Analysis

At first, we considered a relational DB or AWS DynamoDB.
But due to the diverse field structures and complex queries needed for IoT data,
we opted for AWS DocumentDB, which is compatible with MongoDB.

Thanks to DocumentDB’s advantages,
we can run a query like:

“List all machines on Line 3 of Factory A that had more than 3 errors in the last hour”
with a single line of code.

In this post, we focused on the core data pipeline.
In the next part, we’ll show how this data is actually visualized and displayed on the web.

Curious how we turn raw data into live dashboards?

🔽 Check this out:

👉 How Factory Data Moves to Korea’s Dashboard – Part 1