Microservice · Cell-Based Architecture

I kept the existing microservice suite and packaged it into a self-contained cell for each concert on-sale.

ฉันคง Microservice Suite เดิมที่ใช้งานได้ดีอยู่แล้ว และนำมาจัดเป็น Self-Contained Cell สำหรับแต่ละ Concert On-Sale

The full microservice stack is chapter 1 — Monolith → Microservice →

ผัง Microservice ชุดเต็มคือบทที่ 1 — Monolith → Microservice →

But this pattern comes with additional complexity.

แต่ Pattern นี้มาพร้อมกับความซับซ้อนที่เพิ่มขึ้น

•Destroy — the cell needs to be destroyed after the concert on-sale finishes

•Traffic Management (Floodgate) — watch a cell and scale it, or shut the gate when it can’t

•Real-Time Data Sync — the cell is destroyed at the end, so the data has to already be central

•Control Plane — something has to create, manage, and retire cells

•Cell-Based CI/CD — the deployment pipeline has to become cell-aware

•Shared Cell for Small Concerts — cheaper, while still keeping the traffic gated

•Destroy — หลัง Concert On-Sale จบ ต้องสามารถทำลาย Cell ได้

•Traffic Management (Floodgate) — เฝ้าดู Cell และ Scale หรือปิด Gate เมื่อไม่สามารถรองรับต่อได้

•Real-Time Data Sync — เมื่อ Cell ถูกทำลายหลังจบงาน ข้อมูลจึงต้องถูก Sync กลับไปยังระบบกลางแบบ Real-Time

•Control Plane — ต้องมีระบบสำหรับ Create, Manage และ Retire Cell

•Cell-Based CI/CD — Pipeline ต้องถูกออกแบบให้เข้าใจและจัดการ Cell ได้

•Shared Cell for Small Concerts — ลดต้นทุนสำหรับคอนเสิร์ตขนาดเล็ก โดยยังคงควบคุม Traffic ผ่าน Gate

Traffic management and the queue ended up as one component: the Floodgate, in different modes.

Traffic Management และ Queue จึงถูกรวมเป็น Component เดียวกัน คือ Floodgate ซึ่งทำงานในหลาย Mode

I still took the trade. The rest of this is how I paid it.

ฉันยังเลือก Trade-off นี้ และส่วนที่เหลือคือวิธีที่ฉันจัดการกับมัน

1 Concert → 1 Cell

Everything starts at the edge — the layer closest to the user.

ทุกอย่างเริ่มที่ Edge ซึ่งเป็น Layer ที่อยู่ใกล้ผู้ใช้มากที่สุด

I use Cloudflare as the entry point, providing DNS, CDN, WAF, bot protection, and rate limiting in one place.

ผมใช้ Cloudflare เป็น Entry Point ซึ่งรวมทั้ง DNS, CDN, WAF, Bot Protection และ Rate Limiting ไว้ในที่เดียว

For the cell-based architecture, we have a dedicated Router layer whose job is to route each request to the right cell. Here, I use Cloudflare Workers as that router. It runs directly at the edge and acts as a lightweight proxy between the user and the cells.

สำหรับ Cell-based Architecture เราจะมี Layer ที่เรียกว่า Router ซึ่งทำหน้าที่ route แต่ละ request ไปยัง Cell ที่ถูกต้อง ในส่วนนี้ผมใช้ Cloudflare Workers ทำหน้าที่เป็น Router โดยรันอยู่ที่ Edge และทำงานเหมือน Lightweight Proxy ระหว่างผู้ใช้กับแต่ละ Cell

User → Cloudflare → Router → Cell

Every concert gets a static landing page on Cloudflare Pages.

ทุกคอนเสิร์ตจะมีหน้า Landing แบบ Static อยู่บน Cloudflare Pages

Everyone lands here first. Only users who click Book go further, which helps reduce the load on my application servers.

ทุกคนจะเข้ามาที่นี่ก่อน และมีเฉพาะคนที่กด Book เท่านั้นที่จะไปต่อ ซึ่งช่วยลดภาระของ Application Server ลงได้

Instead of serving these pages from my main application servers, I keep them static on Cloudflare Pages. That means the landing pages don’t add unnecessary load to my application servers.

แทนที่จะเอาหน้าเว็บเหล่านี้ไปรันอยู่บน Web หลัก ผมแยกมาเป็น Static บน Cloudflare Pages ทำให้หน้า Landing ไม่ต้องมาเพิ่มภาระให้กับ Application Server

When users click Book, the Worker performs the routing and sends the request to the concert’s cell based on the path.

พอผู้ใช้กด Book Worker จะทำการ Routing แล้วส่ง Request ไปยัง Cell ของคอนเสิร์ตนั้น โดยดูจาก Path

The path tells the Worker which cell the request belongs to.

Path จะเป็นตัวบอก Worker ว่า Request นี้ต้องไปที่ Cell ไหน

Landing Page → Book → Worker → Concert Cell

The Main Cluster sits outside all the cells.

Main Cluster อยู่แยกออกมานอก Cell ทั้งหมด

A cell does one thing: seat booking. Everything else lives here — membership, admin, check-in, and reports.

Cell ทำอย่างเดียวคือจองที่นั่ง ที่เหลืออยู่ตรงนี้หมด — ระบบสมาชิก, Admin, Check-in และ Reports

It auto-scales too. In front of it, I have my own tool called Floodgate, which I built for traffic management and automated scaling.

ฝั่งนี้ก็ Auto-scale เหมือนกัน และด้านหน้าจะมี Tool ที่ผมพัฒนาขึ้นมาเองชื่อ Floodgate ซึ่งใช้สำหรับจัดการ Traffic และทำ Automated Scaling

For example, it can scale the main Web UI to 20 instances, or the main API to 100 instances, based on the workload and rules I define. More importantly, each service scales independently based on its own load.

ตัวอย่างเช่น มันสามารถ Scale Main Web UI ขึ้นไป 20 Instances หรือ Main API ขึ้นไป 100 Instances ได้ ตาม Workload และ Rule ที่ผมกำหนดไว้ ที่สำคัญคือแต่ละ Service สามารถ Scale ได้อย่างอิสระตาม Load ของตัวเอง

The Main Cluster doesn’t need to be split into cells. Shared services like membership stay centralized as a single source of truth. Only booking is isolated into cells, because that’s where we need to separate one event from another.

Main Cluster ไม่จำเป็นต้องแบ่งเป็น Cell เพราะ Shared Services อย่างระบบสมาชิกต้องอยู่รวมกันเป็น Single Source of Truth ส่วนที่แยกเป็น Cell คือ Booking เพราะเราต้องการแยกแต่ละ Event ออกจากกัน

Main Cluster → Membership / Admin / Check-in / Reports

Floodgate → Independent Service Scaling

The Cell is the part that handles the actual seat booking.

Cell คือส่วนที่รับผิดชอบการจองที่นั่งโดยตรง

I designed it so that big concerts get their own cell, while small concerts can share one.

ผมออกแบบให้คอนเสิร์ตใหญ่มี Cell เป็นของตัวเอง ส่วนคอนเสิร์ตเล็กสามารถใช้ Cell ร่วมกันได้

Small concerts share the blast radius, but their traffic is more predictable, and it helps keep the cost down.

คอนเสิร์ตเล็กจะแชร์ Blast Radius กัน แต่ Traffic คาดเดาได้มากกว่า และช่วยควบคุมค่าใช้จ่าย

Multi-AZ is an optional feature in the contract. If a client wants it, they get it.

Multi-AZ เป็น Optional Feature ในสัญญา ถ้าลูกค้าต้องการ ก็สามารถเลือกใช้ได้

Each cell has its own Floodgate too. It supports different modes depending on the event.

แต่ละ Cell ก็มี Floodgate ของตัวเองด้วย โดยรองรับหลาย Mode ขึ้นอยู่กับงาน

Before we size each cell, we need to know its initial capacity. That’s where performance testing comes in.

ก่อนที่เราจะกำหนดขนาดของแต่ละ Cell เราต้องรู้ก่อนว่า Initial Capacity อยู่ประมาณไหน นี่คือเหตุผลที่เราต้องทำ Performance Testing

Performance testing gives us an initial sizing for each cell — the traffic, the number of instances, and the resources it needs.

Performance Testing ช่วยให้เราได้ Initial Sizing ของแต่ละ Cell — ทั้ง Traffic, จำนวน Instance และ Resource ที่ต้องใช้

It’s never exact. In the real world, we never know exactly how much traffic we’ll get.

มันไม่เคยแม่นร้อยเปอร์เซ็นต์ เพราะในโลกจริงเราไม่มีทางรู้ได้แน่นอนว่าจะมี Traffic เข้ามาเท่าไหร่

That’s why I developed Floodgate — to monitor real traffic and scale the cell automatically.

นั่นคือเหตุผลที่ผมพัฒนา Floodgate — เพื่อ Monitor Traffic จริง และ Auto-scale Cell

Big Concert → Dedicated Cell

Small Concerts → Shared Cell

Performance Testing → Initial Sizing → Floodgate → Dynamic Scaling

Four modes — set per event.

Four modes — กำหนดแยกตามแต่ละ Event

The Floodgate is the first thing traffic hits. It monitors the traffic and applies the rules we set.

Floodgate คือด่านแรกที่ Traffic เจอ มัน Monitor Traffic และทำตาม Rule ที่เราตั้งไว้

Which mode is on depends on the event.

ว่าจะเปิด Mode ไหนขึ้นอยู่กับงานนั้น

Queue FIFO — first come, first served. We developed this to replace third-party queueing solutions that were expensive and didn’t fit our needs. For some clients, the queue itself is also part of the experience — a feature, or even a gimmick.

Queue FIFO — ใครมาก่อนได้ก่อน เราพัฒนาขึ้นมาเพื่อใช้แทน Third-party Queue ที่มีราคาแพงและไม่ตอบโจทย์เรา และสำหรับลูกค้าบางราย การต่อคิวก็เป็นส่วนหนึ่งของประสบการณ์ เป็น Feature หรือเป็น Gimmick ได้ด้วย

Admit Rate/s — it controls how many users we allow into the booking flow per second. That rate drives the scaling.

Admit Rate/s — ควบคุมว่าเราจะปล่อย User เข้า Booking Flow ได้กี่คนต่อวินาที และ Rate นี้จะเป็นตัวขับการ Scaling

Max Concurrency — it controls how many users can be active in the booking flow at once. We can keep headroom and scale before we hit the limit.

Max Concurrency — ควบคุมจำนวน User ที่สามารถอยู่ใน Booking Flow พร้อมกัน เราสามารถเผื่อ Headroom และ Scale ก่อนที่จะชน Limit ได้

Block — emergency mode. Say the database spikes. New arrivals go to a waiting room, but anyone already mid-booking keeps going. We only hold the people who haven’t started — to buy us time to investigate and handle the problem while preventing further damage. It’s similar to the principle behind a circuit breaker.

Block — โหมดฉุกเฉิน สมมุติ Database พีค คนที่เพิ่งเข้ามาจะถูกส่งไป Waiting Room แต่คนที่กำลังจองอยู่ทำต่อได้ตามปกติ เรากั้นเฉพาะคนที่ยังไม่เริ่ม เพื่อซื้อเวลาให้เราตรวจและจัดการกับปัญหา โดยป้องกันไม่ให้เกิดความเสียหายเพิ่ม หลักการคล้ายกับ Circuit Breaker

The Queue API is written in Go and runs on a Redis cluster, with DynamoDB for logs.

Queue API เขียนด้วย Go ทำงานบน Redis Cluster และเก็บ Log ไว้ที่ DynamoDB

The waiting room and BFF run on Cloudflare Workers, while the monitoring page is built with React.

Waiting Room และ BFF รันบน Cloudflare Workers ส่วนหน้า Monitoring เป็น React

Traffic → Floodgate → Booking Flow

For booking, this is the same microservice set.

สำหรับ Booking นี่คือ Microservice ชุดเดิมครับ

The full microservice stack is chapter 1 — Monolith → Microservice →

ผัง Microservice ชุดเต็มคือบทที่ 1 — Monolith → Microservice →

We only moved the booking flow into the cell.

เราแค่ย้ายเฉพาะ Booking Flow เข้ามาอยู่ใน Cell

Booking UI, Booking, Inventory, Payment, Cache, and WebSocket Hub.

Booking UI, Booking, Inventory, Payment, Cache และ WebSocket Hub

Everything else stays in the Main Cluster, with the same stack as before — including MQ, retry, and dead-letter queue.

ที่เหลือยังอยู่ใน Main Cluster และใช้ Stack เดิมเหมือนเดิม — รวมถึง MQ, Retry และ Dead-letter Queue

Service Discovery is split by Namespace, so services inside a cell only see their own cell.

Service Discovery แยกตาม Namespace — Service ภายในจึงเจอแค่ของ Cell ตัวเองเท่านั้น

And every service can still scale independently, just like before.

และทุก Service ยังสามารถ Scale ได้อย่างอิสระเหมือนเดิมครับ

Cell → Booking UI → Booking → Inventory / Payment / Cache / WebSocket Hub

The data is isolated per cell too — its own database cluster with replicas, ElastiCache for cache and session, and DynamoDB for queue monitoring.

ฝั่งข้อมูลก็แยกตาม Cell เหมือนกัน — แต่ละ Cell มี Database Cluster ของตัวเอง พร้อม Replica, ElastiCache สำหรับ Cache และ Session และ DynamoDB สำหรับ Queue Monitoring

The components aren’t the point — the point is that every cell has its own.

แต่จริง ๆ แล้ว Component พวกนี้ไม่ใช่ประเด็น ประเด็นคือ ทุก Cell มีของตัวเอง

If one cell’s database goes down, one concert stops. The rest keep selling.

ถ้า Database ของ Cell ไหนล่ม ก็หยุดแค่คอนเสิร์ตนั้น งานอื่นยังขายต่อได้

And the cell’s data syncs back to the central database in real time through CDC.

และข้อมูลจากแต่ละ Cell ก็ Sync กลับไปที่ Database กลางแบบ Real-time ผ่าน CDC

One Cell → One Data Layer → Isolated Failure

Every cell streams its changes to the central database in real time.

ทุก Cell ส่งข้อมูลที่เปลี่ยนแปลงกลับไปที่ Database กลางแบบ Real-time

We have three sync options — Debezium, DMS, and SQS with events.

เรามีวิธี Sync อยู่สามแบบ — Debezium, DMS และ SQS กับ Event

They do the same job. We built and validated all three as alternative approaches, so we can choose the right one for future use.

ทั้งสามแบบทำงานในจุดประสงค์เดียวกัน เราพัฒนาและทดสอบไว้ทั้งหมด เพื่อให้มีทางเลือกและเลือกใช้ให้เหมาะกับอนาคต

The sync makes teardown safe. When an event ends, the Control Plane can destroy the cell because the data is already central — and we can continue using it for Admin, Reporting, and Check-in.

การ Sync แบบนี้ทำให้เราสามารถ Teardown Cell ได้อย่างปลอดภัย พองานจบ Control Plane ก็ Destroy Cell ได้เลย เพราะข้อมูลถูกส่งกลับมาอยู่ที่ส่วนกลางแล้ว และเรายังเอาข้อมูลไปใช้ต่อกับ Admin, Reporting และ Check-in ได้

Central runs on Aurora Global, with a writer and reader across two zones, behind RDS Proxy.

Central รันบน Aurora Global โดยมี Writer และ Reader กระจายอยู่คนละ AZ และอยู่หลัง RDS Proxy

The DR region is storage only. No running instance, no read traffic. If the primary region fails, we provision an instance there and promote it.

ส่วน DR มีไว้เก็บ Data อย่างเดียว ไม่มี Instance รันอยู่ และไม่มี Read Traffic ถ้า Primary Region ล่ม เราค่อย Provision Instance ที่ DR แล้ว Promote ขึ้นมา

We keep the data ready, without keeping another cluster running.

เราเลยเตรียม Data ให้พร้อมสำหรับ DR ได้ โดยไม่ต้องเปิดอีก Cluster ทิ้งไว้ตลอดเวลา

Cell → CDC → Central Data → Admin / Reporting / Check-in

Once the booking is complete, we move to what happens after payment.

ทีนี้มาดูกันว่า หลังจาก Payment สำเร็จแล้ว ระบบทำอะไรต่อ

Ticket generation came from the same stack, but it’s serverless and event-driven.

ระบบออกตั๋วยังใช้ Stack เดิม แต่เราแยกส่วนนี้ออกมาเป็น Serverless และ Event-driven เพราะมันไม่จำเป็นต้องอยู่ใน Request Path ของการจอง และไม่จำเป็นต้องมี Server รอรับงานตลอดเวลา

Payment succeeds, and the event fans out. A Lambda generates the QR and PDF and stores them in S3.

พอ Payment สำเร็จ Event ก็ Fan-out ออกไป แล้ว Lambda จะสร้าง QR กับ PDF และเก็บไว้ที่ S3

It doesn’t need its own cell. It’s isolated by Namespace and has its own bucket.

ส่วนนี้ไม่ต้องมี Cell ของตัวเอง เพราะไม่ได้เป็นส่วนของ Booking ที่ต้องรับ Traffic Burst โดยตรง เราแยกด้วย Namespace และมี Bucket ของตัวเอง

The files are backed up to R2 as well.

ไฟล์ก็ยัง Backup ไปที่ R2 ด้วย

Notifications use the same fan-out event — transaction status goes to the customer, and sales reports go to KOPIS, Korea’s performing arts box office system.

ฝั่ง Notification ก็ใช้ Fan-out Event เดียวกัน — สถานะ Transaction ส่งให้ลูกค้า ส่วน Sales Report ส่งไปที่ KOPIS ซึ่งเป็นระบบ Box Office สำหรับงานศิลปะการแสดงของเกาหลี

It’s serverless because none of this needs a server running all day. It only runs when there’s work.

ดังนั้นหลัง Payment สำเร็จ งานพวกนี้จะแยกออกจาก Booking Flow และทำงานตาม Event ที่เข้ามา ไม่ต้องมี Server รันค้างไว้ตลอดเวลา มีงานเข้ามาค่อยทำงาน

Payment → Fan-out Event → Ticket Generation / Notification

Observability is the Grafana stack — Loki for logs, Tempo for traces, and Prometheus for metrics.

ฝั่ง Observability ใช้ Grafana Stack — Loki เก็บ Log, Tempo เก็บ Trace และ Prometheus เก็บ Metric

It’s centralized, not per cell. The whole platform is monitored from one place.

Observability ส่วนนี้เราเก็บไว้ที่ Central ไม่ได้แยกตาม Cell ทำให้ทั้ง Platform Monitor ได้จากที่เดียว

Everything carries one tag: the cell name.

ทุกอย่างติด Tag เดียวกัน — ชื่อ Cell

So one dashboard covers the whole platform, and one filter narrows it down to a single concert.

Dashboard เดียวจึงดูได้ทั้ง Platform และ Filter เดียวก็สามารถเจาะลงไปดูคอนเสิร์ตเดียวได้

Centralized Observability → Platform-wide View → Cell-level Filtering

One more important service is the Cell Control Plane.

อีกหนึ่ง Service ที่สำคัญคือ Cell Control Plane

Something has to create a cell and destroy it. That’s the control plane — Step Functions, with a cell registry in DynamoDB.

ต้องมีอะไรสักอย่างที่สร้าง Cell และทำลายมัน นั่นคือ Control Plane — Step Functions กับ Cell Registry บน DynamoDB

A cell has a lifecycle: provision, active, sales closed, drain, verify, snapshot, destroy.

Cell มีวงจรชีวิต — Provision, Active, Sales Closed, Drain, Verify, Snapshot แล้วค่อย Destroy

Before anything is deleted, several key checkpoints have to pass, such as: Tickets match. Money reconciles three ways. Seats balance. Queues and dead-letter queues are empty. CDC lag is zero.

ก่อนจะลบอะไรก็ตาม ต้องผ่าน Key Checkpoints ที่สำคัญก่อนครับ เช่น Ticket ต้องตรงกัน เงินต้องกระทบยอดครบสามทาง Seat ต้องบาลานซ์ Queue และ Dead-letter Queue ต้องว่าง และ CDC Lag ต้องเป็นศูนย์

If any one of them is red, the workflow halts. Nothing gets deleted.

ถ้ามีข้อไหนแดง Workflow หยุดทันที ไม่ลบอะไรเลย

Compute and Redis go first — they’re disposable. The database is only stopped, and deleted seven days later.

Compute กับ Redis ไปก่อน เพราะเป็น Resource ที่สร้างใหม่ได้ ส่วน Database แค่ถูกหยุด แล้วลบอีกทีในเจ็ดวัน

Everything else can be rebuilt. Deleted data can’t — so that’s the one step the automation doesn’t get to decide alone.

อย่างอื่นสร้างใหม่ได้หมด ข้อมูลที่ถูกลบไม่ได้ — ขั้นตอนนั้นเลยเป็นขั้นเดียวที่ระบบอัตโนมัติไม่มีสิทธิ์ตัดสินเองครับ

Control Plane → Lifecycle → Safety Checks → Halt on Failure → Delayed DB Deletion

Blast Radius Is a Design Choice

Blast Radius Is a Design Choice

Shifted from system-wide risk to unit-level isolation across 5 core dimensions:

ปรับเปลี่ยนจากการแบกรับความเสี่ยงทั้งระบบ ไปสู่การแยกส่วนความเสียหายอย่างสิ้นเชิงใน 5 มิติ:

01— Risk: Isolatedfailure in one event never cascades.

01— ความเสี่ยง (Risk): ถูกจำกัดวงความผิดพลาดในคอนเสิร์ตเดียว จะไม่มีวันส่งผลกระทบลามไปทั้งแพลตฟอร์ม

02— Resource & Capacity: Isolatedheavy traffic spikes stay contained.

02— ทรัพยากร (Resource & Capacity): ถูกแยกส่วนทราฟฟิกมหาศาลที่พุ่งสูง จะถูกกักไว้เฉพาะจุด

03— Budget: Isolatedcost is strictly allocated per workload unit.

03— งบประมาณ (Budget): ถูกควบคุมต้นทุนโครงสร้างพื้นฐานคำนวณแยกตามหน่วยการทำงานจริง

04— Scaling: Independentscale only what needs to scale.

04— การขยายระบบ (Scaling): เป็นอิสระขยายศักยภาพเฉพาะส่วนที่ต้องการ โดยไม่เปลืองทรัพยากรรวม

05— Operations: Independentdeployments or maintenance happen without platform downtime.

05— การปฏิบัติการ (Operations): เป็นอิสระอัปเดตหรือซ่อมบำรุงระบบได้ โดยไม่ต้องปิดบริการทั้งแพลตฟอร์ม

The goal is simple: One concert can fail without taking the rest of the platform down.

เป้าหมายเรียบง่ายแต่เด็ดขาด: แม้ระบบของคอนเสิร์ตหนึ่งจะล้มลง แต่บริการส่วนอื่นทั้งหมดต้องยังคงเปิดทำงานได้ตามปกติ