Series MQTT & IoT – Bài 4: Thiết kế topic chuẩn để mở rộng 10 → 10.000 devices (naming, org/device, versioning)

Khi số lượng thiết bị IoT tăng từ vài cái lên hàng trăm, hàng nghìn, topic MQTT trở thành “xương sống” của toàn bộ hệ thống. Trong bài này, bạn sẽ học cách thiết kế topic chuẩn với cấu trúc rõ ràng (org / project / device), tách telemetry–status–event và chuẩn bị sẵn versioning để mở rộng từ 10 lên 10.000 thiết bị mà không cần refactor lại hệ thống.

1) Vì sao thiết kế topic là “xương sống” của hệ thống IoT?

Ở giai đoạn đầu (1–5 thiết bị), nhiều maker thường dùng topic kiểu:

/test
/esp32/data
/myhome/sensor

👉 Chạy được, nhưng khi số thiết bị tăng, bạn sẽ gặp:

Không phân biệt được thiết bị nào gửi
Không tách được telemetry / status / event
Khó viết rule cảnh báo
Không thể cấp quyền theo device/user
Muốn thêm dashboard / service mới → rất rối

Topic MQTT không chỉ để gửi dữ liệu, nó chính là hợp đồng (contract) giữa:

Firmware
Cloud ingest
Dashboard
Rule / Alert / API

2) Nguyên tắc vàng khi thiết kế topic MQTT

Hãy nhớ 5 nguyên tắc này:

Phân cấp rõ ràng (hierarchical)
Không phụ thuộc firmware logic
Dễ subscribe theo nhóm (wildcard)
Tách loại dữ liệu (telemetry / status / event)
Chuẩn bị sẵn cho versioning

3) Cấu trúc topic khuyến nghị (chuẩn IoTLabs)

Một cấu trúc tổng quát nên dùng:

<iot>/<org>/<project>/<device>/<data_type>

Ví dụ cụ thể:

iotlabs/org_01/greenhouse/d_001/telemetry
iotlabs/org_01/greenhouse/d_001/status
iotlabs/org_01/greenhouse/d_001/event

Ý nghĩa từng tầng

Phần	Ý nghĩa
`iotlabs`	Namespace / platform
`org_01`	Tổ chức / người dùng
`greenhouse`	Project / nhóm thiết bị
`d_001`	Device ID
`telemetry`	Loại dữ liệu

👉 Nhìn topic là biết ngay dữ liệu đến từ đâu và dùng để làm gì.

4) Tách rõ theo loại dữ liệu (bắt buộc)

Luôn luôn tách topic theo data_type:

.../telemetry
.../status
.../event

Vì sao bắt buộc?

Backend ingest xử lý khác nhau
Dashboard hiển thị khác nhau
Rule cảnh báo thường chỉ quan tâm status / event

❌ Không nên:

.../data
.../all

5) Wildcard — vũ khí để scale

MQTT cho phép subscribe bằng wildcard:

+ : 1 level
# : nhiều level

Ví dụ cực kỳ quan trọng

Subscribe toàn bộ telemetry của 1 project:

iotlabs/org_01/greenhouse/+/telemetry

Subscribe tất cả event của toàn bộ hệ thống:

iotlabs/org_01/#

👉 Nhờ wildcard, bạn có thể:

Thêm device mới không cần sửa code backend
Gắn thêm dashboard / service mới rất nhanh

6) Thiết kế cho phân quyền & bảo mật

Topic chuẩn giúp bạn:

Cấp quyền per-device
Không cho device đọc dữ liệu của device khác

Ví dụ quyền publish cho device d_001:

Allow publish: iotlabs/org_01/greenhouse/d_001/#
Deny publish:  iotlabs/org_01/greenhouse/+/status

👉 Thiết bị chỉ được gửi data của chính nó.

7) Versioning topic — chuẩn bị cho tương lai

Khi hệ thống lớn dần, payload sẽ thay đổi.

Đừng phá hệ thống cũ → hãy dùng versioning.

Cách 1: Version trong topic (khuyến nghị)

iotlabs/v1/org_01/greenhouse/d_001/telemetry
iotlabs/v2/org_01/greenhouse/d_001/telemetry

Ưu điểm:

Backend subscribe song song v1 & v2
Rollout dần dần

Cách 2: Version trong payload (chỉ nên dùng khi nhỏ)

{
  "version": 1,
  "ts": 1768,
  "metrics": { ... }
}

8) Mapping topic → dashboard (tư duy đúng)

Topic	Dashboard
`.../telemetry`	Chart, latest value
`.../status`	Online/Offline, health card
`.../event`	Timeline, alert list

👉 Topic định nghĩa UI, không phải UI đoán payload.

9) Sai lầm phổ biến khi thiết kế topic

❌ Gộp nhiều device chung 1 topic
❌ Dùng tên mơ hồ (data, info)
❌ Không chừa đường versioning
❌ Topic quá ngắn, thiếu ngữ cảnh
❌ Topic thay đổi theo logic firmware

10) Checklist thiết kế topic “production-ready”

Có org / project / device rõ ràng
Tách telemetry / status / event
Dùng wildcard được
Hỗ trợ phân quyền
Có versioning

11) Kết luận

Thiết kế topic tốt giúp bạn:

Scale từ 10 → 10.000 devices mà không phải refactor
Dễ viết dashboard & rule
Dễ debug & bảo mật
Dễ phát triển sản phẩm lâu dài

Topic MQTT tốt = hệ thống IoT sống lâu.

Bài tiếp theo trong series

Bài 5: QoS 0/1/2 dùng khi nào? Bảng quyết định nhanh theo use-case

IoTLabs