Blogs on Nextjingjing

Microservice ตอนที่ 4 Queries in Microservice

Sat, 11 Apr 2026 00:00:00 +0000

การทำ Query ใน Microservice

การ Query เพื่อขออ่านจากหลายๆ Databases เป็นเรื่องที่ท้าทายกว่า Monolith เพราะแต่ละ Service ใน Microservice นั้นต่างก็มี Database เป็นของตนเอง

ประเภทของการทำ Query Microservice

แบ่งออกเป็น 2 รูปแบบ ได้แก่

API composition pattern (รูปแบบการประกอบ API)
Command query responsibility segregation (CQRS) pattern

API composition pattern

ลักษณะ

Provider service เป็น Service ที่มี Database ให้บริการ
API composer ทำหน้าที่เรียก Service ต่างๆ เพื่อ Query ข้อมูลออกมาจากแต่ละ Service ที่มี Database เป็นของตนเอง
- ใครทำหน้าที่เป็น API composer ได้บ้าง
  - API Gateway ก็ได้
  - Backend for frontend (ทำเป็นอีก Service แยกสำหรับการ Query ก็ได้)
  - Frontend ก็ได้ แต่จะเปลืองเน็ตผู้ใช้เพราะต้องเรียก Service เองหลายๆ Request
- ควรเรียก Provider service แบบขนานพร้อมกันให้ได้มากที่สุดเท่าที่จะเป็นไปได้

ข้อดี

ทำได้ง่ายกว่า CQRS มากๆ

ข้อเสีย

อาจจะมีประสิทธิภาพต่ำ
- ลองคิดว่าเราต้อง Join table ขนาดใหญ่ๆ หลายๆตาราง กรณีนี้เราจะเปลือง Memory มากๆ
อาจจะลด Availability เพราะทุกๆ Service ต้องทำงานพร้อมกัน
- ทางแก้: หากมีบาง Service ล่ม ให้ส่งข้อมูลที่มีและไม่ต้องส่งข้อมูลที่ล่มให้ผู้ใช้และอย่าลืมบอกว่า Service ล่มด้วย
มีสิทธิ์ที่จะได้ข้อมูลที่ Inconsistency (ไม่ถูกต้องสอดคล้อง)
- ทางแก้: ต้องทำโค้ดตรวจจับอาการผิดปกติ เช่น อาจจะให้ API composer ส่ง Version Token ไปให้ผู้ใช้ทุกครั้ง โดย Version Token นี้ใช้เพื่อดูว่า Query ผู้ใช้เก่าแล้วหรือยัง?ดังนั้น API composer จะเช็คว่า Version Token ตรงกับเวอร์ชั้นล่าสุดไหม?

Command query responsibility segregation (CQRS) pattern

ทำไมต้องใช้ CQRS ?

เพราะ API composition pattern ถ้าเกิดต้อง Join table ตารางขนาดใหญ่ ทำให้เปลือง Memory มากๆ
Service ใช้ Database ที่ Query ไม่เก่ง
- เช่น DynamoDB ไม่สามารถ Query อย่างอื่นนอกจาก Primary key ได้เลย
Separate concerns การแยกการอ่านกับการเขียนเพราะเขียนความถี่น้อยกว่าอ่านมากๆ ทำให้แยกจะดีกว่า (จะได้ไม่ค้างทั้งระบบ)
- เช่น การค้นหาสถานที่สักอย่างใกล้ฉัน (Geo-spatial Query) มันเป็นภาระที่หนักมากๆ ทีม dev จึงนิยมแยกมันไปอยู่อีก Service ไปเลย

ลักษณะ

Aggregate เราจะกล่าวกันต่อในบทหลังๆ

graph TD
 %% Global Style
 classDef serviceBox fill:#d1f0ff,stroke:#333,stroke-width:2px;
 classDef yellowBox fill:#fff9c4,stroke:#333,stroke-width:1.5px;
 classDef purpleBox fill:#d1c4e9,stroke:#333,stroke-width:1.5px;
 classDef whiteBox fill:#fff,stroke:#333,stroke-width:1px;

 Title(CQRS) --- CRUD((CRUD operations))
 CRUD --- Router

 subgraph Service [Service]
 direction TB
 Router[ ]:::whiteBox
 
 subgraph CommandSide [Command/domain model]
 direction TB
 Agg1[Aggregate]:::whiteBox
 Agg2[Aggregate]:::whiteBox
 end

 subgraph QuerySide [Query model]
 direction TB
 EH[Event handler]:::whiteBox
 end
 
 Router -- CUD --> CommandSide
 Router -- R --> QuerySide
 
 CommandSide -- Events --> EH
 end

 CommandSide --- CDB[(Command-side
database)]
 QuerySide --- QDB[(Query database)]

 %% Apply Classes
 class Service serviceBox;
 class CommandSide,QuerySide yellowBox;
 class CDB,QDB purpleBox;

เราจะแยก Database ของการอ่าน (Query-side) กับการเขียน (Command-side) ออกจากกัน โดยจะ Sync กันด้วยการส่ง Event เพื่อสื่อสารแลกเปลี่ยนข้อมูลให้ข้อมูลทั้งสองตรงกัน (Query-side จะ Copy ตาม Command-side)
- Database เป็นคนละเทคโนโลยีกันได้
  - ข้อดี: ทำให้แก้ปัญหา Database ฝั่ง Command-side ไม่เก่ง Query ดังนั้น Database ฝั่ง Query-side สามารถเลือก Database ที่ Query เก่งๆ ได้
เราจะแยกการเขียน (CUD) และการอ่าน (R) ออกจากกัน
- Command-side จะทำหน้าที่รับคำสั่งเขียน (CUD) และจะส่ง Event (ผ่าน Message broker) ไปบอกว่าสร้างข้อมูลอะไรเพื่อ Sync ข้อมูลให้ตรงกัน
- Query-side จะทำหน้าที่รับคำสั่งอ่าน (R) และจะมี Event handler ไว้รับข้อมูลการสร้างข้อมูลจากฝั่ง Command-side เพื่อ Sync ข้อมูลให้ตรงกัน
ฝั่ง Query-side ต้องอยู่ใน Service ไหน แยกเป็นอีก Service พิเศษดีไหม?
- คำตอบ แน่นอนแยกเป็นอีก Service ดีที่สุด เช่น

graph LR
 classDef serviceNode fill:#d1f0ff,stroke:#333,stroke-width:1px;
 classDef handlerNode fill:#c8e6c9,stroke:#333,stroke-width:1px;
 classDef databaseNode fill:#d1c4e9,stroke:#333,stroke-width:1px;
 classDef interfaceNode fill:#fff,stroke:#333,stroke-width:1px;

 subgraph Commands [Command Side - Write]
 direction TB
 style Commands fill:none,stroke:none;

 Cart_API(( )):::interfaceNode --- CS[Cart & Checkout Service]:::serviceNode
 Payment_API(( )):::interfaceNode --- PS[Payment Service]:::serviceNode
 Inv_API(( )):::interfaceNode --- IS[Inventory Service]:::serviceNode
 Ship_API(( )):::interfaceNode --- SS[Shipping Service]:::serviceNode
 end

 CS -- "Checkout
events" --> EH
 PS -- "Payment
events" --> EH
 IS -- "Stock
events" --> EH
 SS -- "Tracking
events" --> EH

 subgraph QuerySide [Query Side - Read]
 direction TB
 style QuerySide fill:none,stroke:none;
 
 View_API(( )):::interfaceNode --- View_Label["getMyOrders()
trackShipment()"]
 View_Label --- OVS[Order View Service]:::serviceNode
 OVS --- DB[(Query
Database)]:::databaseNode
 end

 EH[Event
Handlers]:::handlerNode --- OVS

จากรูปเราแยก Service สำหรับ Query ออกมาเป็น Service พิเศษ (จากรูปคือ Order View Service) และให้มันแลกเปลี่ยนข้อมูลกับ Service ที่มี Database ที่ต้องการ (จากรูปคือ Cart & Checkout Service, Payment Service, Inventory Service และ Shipping Service)

ข้อดี

ประสิทธิภาพของการ Query สูงกว่า
แยกการเขียนและการอ่านออกจากกันชัดเจน (Separate concerns)
- ดีกับระบบที่อ่านเยอะกว่าเขียนมากๆ

ข้อเสีย

มีความซับซ้อนสูงมาก
อาจจะมี Lag ของ Command-side กับ Query-side ทำให้เกิด Inconsistency ของข้อมูล
- แก้ได้

คำแนะนำ

Important Note 📝:

เราควรใช้ API composition pattern เป็นตัวเลือกแรก และใช้ CQRS เมื่อจำเป็นเท่านั้น เช่น

Database ของ Service ที่สนใจมี Query ที่ไม่เก่ง

ภาระการอ่านเยอะกว่าเขียนมากๆ

ต้อง Join table ขนาดใหญ่ ทำให้ Memory ใช้เยอะ

การ Implement ของ CQRS

การเลือก Database ของฝั่ง Query

อยากอ่านไวที่สุด ไม่สนความสัมพันธ์ = NoSQL (Document Store)
อยาก Search ชื่อสินค้า/บทความ เก่งๆ = Search Engine (Elasticsearch)
อยากทำ Dashboard/Report ซับซ้อน = SQL (RDBMS)
ไม่แน่ใจ แต่อยากได้ความยืดหยุ่น = SQL (PostgreSQL)

ป้องกัน Duplicated messages

มีตารางไว้จด Event ที่เคย Process ไปแล้ว PROCESSED_EVENTS เพื่อป้องกันการซ้ำการส่งของ Message Broker

ป้องกัน Inconsistency

ใช้ Version token เพื่อเช็คว่า Query ของผู้ใช้เก่าไปแล้วหรือไม่ เพราะเมื่อมีการอัพเดต database ตลอดมีโอกาสที่ผู้ใช้จะมี Query ที่ยังไม่อัพเดต

ป้องกัน Concurrency ใน Record เดียวกัน

ใช้ Pessimistic locking เช่น SELECT ... FOR UPDATE;
ใช้ Optimistic locking เช็คว่า Version ตรงกับปัจจุบันหากไม่ตรงแสดงว่ามีคนเขียนก่อนเรา เช่น WHERE version = current_version

← หน้าก่อนหน้า

ตอนถัดไป →

Microservice ตอนที่ 3 saga pattern

Tue, 07 Apr 2026 00:00:00 +0000

การจัดการกับ Transaction ด้วย saga pattern

เนื่องจาก Microservice แต่ละ Service มี Database เป็นของตนเอง การจัดการกับ Transaction จึงแตกต่างออกไปจาก Monolith อย่างมาก

ก่อนมี saga Pattern

ก่อนมี saga Pattern นั้น การทำ Microservice ต้องจัดการ Transaction ด้วย Distributed Transaction ได้แก่ 2-Phase Commit (2PC) คือการที่ให้ทุกๆ Database ในระบบต้อง Commit ให้ครบ หากไม่ครบ จะ Rollback กลับทั้งหมด “All-or-Nothing”

2PC ทำให้เกิดความเป็น ACID (Atomicity, Consistency, Isolation, Durability)

แต่ปัญหาของวิธีการ 2PC ดังกล่าว คือ High coupling หากมี Service ไหนตาย จะตายกันทั้งระบบ

ดังนั้นหากจะทำให้ไม่เกิดปัญหานี้เราจะต้องยอมให้แต่ละ Database commit เองไปเลยแล้วหากต้อง Rollback ก็ค่อยหาทางยกเลิกผลของ Commit ทั้งหมดที่เคย Commit ไป นี้แหละแนวคิดของ saga Pattern

saga Pattern

ลักษณะ

graph LR
 subgraph Saga [Saga Pattern Execution]
 direction LR
 OS1[Order Service
Local Transaction]
 CS[Customer Service
Local Transaction]
 OS2[Order Service
Local Transaction]

 OS1 -- "Message/Event" --> CS
 CS -- "Message/Event" --> OS2
 end

 style OS1 fill:#c1fba4,stroke:#333
 style CS fill:#c1fba4,stroke:#333
 style OS2 fill:#c1fba4,stroke:#333

แต่ละ Service มี Local Transaction และต่อกันเป็นลำดับของ Local Transaction
ทุกครั้งที่แต่ละ Local Transaction นั้นมีการ Commit จะส่ง Asynchronous Message/Event ไปบอก Service ตัวถัดไปให้ทำงานต่อตนเอง
- ห้ามใช้ Synchronous (เช่น HTTP Rest หรือ gRPC) เด็ดขาดเลย เพราะจะเกิด High Coupling
SAGA ไม่มีการ Rollback แต่จะยกเลิกผลของการ Commit โดยการ Compensating transactions (การชดเชย) แทนที่การ Rollback
- เช่น พอ Commit เงินเป็น 100 บาท แต่พอต้องทำ Compensating transactions ต้องโดน -100 บาทนั้นทิ้ง แทนการ Rollback เพราะ Commit ไปแล้ว

Important Note 📝:

Compensating transactions ใช้ Undo การกระทำที่ commit ไปแล้วแทนที่การ Rollback

ข้อดี

Loose coupling หากมีคนตายไม่ตายทั้งระบบ

ข้อเสีย

ซับซ้อนวุ่นวายกว่า
ใช้ Rollback ไม่ได้ ต้องคิด Logic ของ Compensating transactions

ปัญหา

ไม่ครบ ACID เพราะขาด Isolation ไป (แก้ได้ ✅)
- เดี๋ยวคุยรายละเอียดในหัวข้อหลังๆ

Compensating transactions

Compensating transactions ใช้ Undo การกระทำที่ commit ไปแล้วแทนที่การ Rollback เช่น โอนเงิน 100 บาท จะชดเชยโดยการถอนเงิน 100 บาทคืน เป็นต้น หากเกิด Failure ขึ้น ระบบจะไม่ส่ง Asynchronous Message/Event ไปให้ SAGA ลำดับถัดไป แต่จะทำการชดเชย Local Transaction ตัวก่อนๆ เช่น

SAGA pattern ที่มีลำดับ 1, 2, 3, 4(❌), 5, 6 หาก Failure ที่ 4 เราจะไม่ส่ง Message ไปบอก 5 ให้ทำงาน และจะทำการ Compensating transactions ชดเชยตัวก่อนๆ

ลำดับของการชดเชย

sequenceDiagram
 participant S1 as Service 1 (Order)
 participant S2 as Service 2 (Stock)
 participant S3 as Service 3 (Payment)
 participant S4 as Service 4 (Shipping)

 Note over S1,S4: Forward Steps
 S1->>S1: Execute & Commit (1)
 S1->>S2: Next Step
 S2->>S2: Execute & Commit (2)
 S2->>S3: Next Step
 S3->>S3: Execute & Commit (3)
 S3->>S4: Next Step
 
 Note right of S4: ❌ Step 4 Fails!
 S4-->>S4: Abort (4)

 Note over S1,S3: Compensation Path (Reverse Steps)
 S4-->>S3: Trigger Compensation
 S3->>S3: Undo Actions (Compensate 3)
 S3-->>S2: Trigger Compensation
 S2->>S2: Undo Actions (Compensate 2)
 S2-->>S1: Trigger Compensation
 S1->>S1: Undo Actions (Compensate 1)
 
 Note over S1,S4: System back to Consistent State

จากภาพจะเห็นว่าลำดับการทำงานของ SAGA คือ Order, Stock, Payment, Shipping แต่ที่ Shipping เกิดล้มเหลวขึ้นมา ลำดับการชดเชยจึงเป็น Payment, Stock, Order เป็นลำดับย้อน (Reverse Order)

Important Note 📝:

Compensating transactions จะเป็นลำดับย้อน (Reverse Order) ของลำดับใน SAGA ก่อน Local Transaction ที่ล้มเหลว

เช่น 1 commit, 2 commit, 3 commit, 4 failure จะมีลำดับชดเชยเป็น 3, 2, 1

บาง Transaction อาจจะไม่จำเป็นต้องเกิดการชดเชย

บาง Transaction อาจจะไม่จำเป็นต้องเกิดการชดเชย เช่น พวก Transaction ที่เป็น Read-Only

เช่น จากตารางจะเห็นได้ว่า verifyConsumerDetails() ไม่ต้อง Compensating transaction เพราะตัวเองเป็น Read-Only

State	Service	Transaction	Compensating transaction
Commit	Order Service	createOrder()	rejectOrder()
Commit	Consumer Service	verifyConsumerDetails()	—
Commit	Kitchen Service	createTicket()	rejectTicket()
Failure	Accounting Service	authorizeCreditCard()	—
-	Kitchen Service	~~approveTicket()~~	—
-	Order Service	~~approveOrder()~~	—

โครงสร้างของ saga

Type	Service	Transaction
Compensatable transactions	Order Service	createOrder()
Compensatable transactions	Consumer Service	verifyConsumerDetails()
Compensatable transactions	Kitchen Service	createTicket()
Pivot transactions	Accounting Service	authorizeCreditCard()
Retriable transactions	Kitchen Service	approveTicket()
Retriable transactions	Order Service	approveOrder()

Compensatable transactions คือ Transactions ทียอมให้เกิด Compensating ได้
Pivot transactions คือ Transactions ทีเป็นจุดตัดสินใจว่า saga นี้จะสำเร็จ หรือจะต้องไปทำ Compensating Transaction แทน
Retriable transactions คือ Transactions ที่จะไม่ทำ Compensating แต่ถ้า Failure เกิดขึ้นที่นี้ต้อง Retry จนกว่าจะสำเร็จ

Implementation ของ saga pattern

ประเภทของ saga pattern

Choreography-based sagas (ไร้คนคุม)
Orchestration-based sagas (มีคนคุม)

Choreography-based sagas

ลักษณะ

ไม่มีใครคุมลำดับของ saga
- Service พอทำ Local Transaction ของตนเองเสร็จจึง Message ไปบอก Service ตัวถัดไปเป็นทอดๆ โดยไม่มีใครคุมมัน

ข้อดี

Loose coupling เพราะไม่มี Service ไหนรู้จักกันตรงๆ เลย
ถ้าลำดับของ saga ไม่ยาวมาก Choreography-based sagas ตอบโจทย์

ข้อเสีย

ซับซ้อนเพราะพอมีไม่คนคุมลำดับ saga ต้อง implement ให้แต่ Service รับมือเอง
- code กำหนดลำดับของ saga ไม่ได้อยู่จุดเดียว กระจายตัวไปตามแต่ละ Service
เข้าใจยากหาก saga มีลำดับยาว

Orchestration-based sagas

ลักษณะ

มีใครคุมลำดับของ saga
- มี Service ที่สร้าง saga ขึ้นมาและเป็นคนคมลำดับของ saga โดยอันนี้จะแตกต่างจาก saga ปกตินิดนึง

โดยปกติแล้ว saga จะทำงานแบบส่งต่อกันเป็นทอดๆ ตัวอย่างเช่น

graph LR
 subgraph Saga [Choreography-based saga]
 direction LR
 OS1[Order Service
Local Transaction]
 CS[Customer Service
Local Transaction]
 OS2[Order Service
Local Transaction]

 OS1 -- "Message/Event" --> CS
 CS -- "Message/Event" --> OS2
 end

 style OS1 fill:#c1fba4,stroke:#333
 style CS fill:#c1fba4,stroke:#333
 style OS2 fill:#c1fba4,stroke:#333

แต่ใน Orchestration-based saga จะเปลี่ยนเป็นการที่ให้ Service (Orchestrator) หนึ่งควบคุม saga ไปเลย

ส่วน Service อื่นๆ เมื่อก็รอให้ Orchestrator มาสั่งงานตนเอง

sequenceDiagram
 participant S1 as Order (Orchestrator)
 participant S2 as Stock
 participant S3 as Payment
 participant S4 as Shipping

 Note over S1: เริ่ม Saga
 S1->>S2: 1. สั่งจองสต็อก
 S2-->>S1: 2. จองสำเร็จ
 
 S1->>S3: 3. สั่งตัดเงิน
 S3-->>S1: 4. ตัดเงินสำเร็จ
 
 S1->>S4: 5. สั่งเตรียมส่งของ
 S4-->>S1: 6. เตรียมส่งสำเร็จ
 
 Note over S1: จบ Saga (Complete)

จากภาพจะเห็นว่าการสื่อสารจะกลับมาที่ Order (Orchestrator) ตลอด saga เลย

ข้อดี

ถ้า saga มีลำดับยาวและซับซ้อน Orchestration-based saga จะตอบโจทย์กว่า
Code ที่กำหนดลำดับของ saga อยู่ในที่เดียว

ข้อเสีย

Orchestrator มี Business logic เยอะเกินไป
- แก้ได้โดยแยกเป็นอีก Service ไปเลย เช่น Order Service แยกเป็น Order Service + OrderOrchestrator แทน
Tight Coupling ที่ตรง Orchestrator เพราะต้องรู้จักทุกๆ Service

Important Note 📝:

Orchestrator มี Business logic เยอะเกินไป สามารถแก้ได้โดยแยกเป็นอีก Service ไปเลย เช่น Order Service แยกเป็น Order Service + OrderOrchestrator แทน

คำแนะนำ

Important Note 📝:

Chris Richardson (คนเขียน Microservices Patterns: With Examples in Java) แนะนำว่าให้ใช้ Orchestration-based sagas ทุกกรณี

ยกเว้นว่า saga แบบเรียบง่ายมากๆ สามารถใช้ Choreography-based sagas แทนได้

เทคโนโลยีและเครื่องมือยอดนิยมสำหรับ Orchestration Saga
- Temporal.io
- Camunda
- AWS Step Functions
- … เป็นต้น

การรับมือกับการขาด Isolation ของ ACID ใน saga pattern

ปัญหา

Isolation คือ กฏที่ช่วยให้ Transaction นั้นเกิด Consistency (ความถูกต้องของข้อมูล) แต่พอขาด Isolation ใน saga ไปแล้วอาจจะเกิดปัญหา Lost Updates, Dirty Reads ขอยกตัวอย่างเพื่อความเข้าใจง่ายขึ้น

ตัวอย่างที่ 1 Lost Updates

saga A กำลังอัพเดต Order X
saga B กำลังยกเลิก Order X และ Commit แล้ว
saga A อัพเดต Order X เสร็จและ Commit แล้ว

แบบนี้มีสิทธิ์ที่การยกเลิกจะหายไปเลย

ตัวอย่างที่ 2 Dirty Reads

นาย X มีเงิน 0 บาท
saga A อัพเดตให้และ commit ทำให้นาย X มีเงิน 200 บาท แต่ยังไม่จบ saga A
saga B อ่านเงินนาย X และเห็นว่ามีเงิน 200 บาท
ต่อมา saga A เกิด Failure เลยทำการ Compensating transactions
- ทำให้นาย X มีเงิน 0 บาท
หากว่า saga B ยังไมจบ มันจะเอาค่าไปใช้แบบผิดๆ

การแก้ปัญหา

Semantic lock

เพิ่ม state มาเป็น field พิเศษไว้บอก saga อื่นๆ ว่า record นั้นกำลังถูกใช้งานอยู่โดยใช้ *_PENDING เพื่อบอกว่ากำลังใช้งาน และค่อยตัด _PENDING ทิ้งเมื่อ saga ทำงานจนครบลำดับ เช่น

Order table

id create_at … state

1 2026-01-01 … APPROVAL_PENDING

2 2026-01-01 … REVISION_PENDING

เมื่อ saga ทำงานสำเร็จเราจะตัด _PENDING ทิ้งไป (ในที่นี้ Order Service ต้องอัพเดตดังนี้)

Order table

id create_at … state

1 2026-01-01 … APPROVAL

2 2026-01-01 … REVISION

id	create_at	…	state
1	2026-01-01	…	APPROVAL_PENDING
2	2026-01-01	…	REVISION_PENDING

id	create_at	…	state
1	2026-01-01	…	APPROVAL
2	2026-01-01	…	REVISION

เมื่อ saga อื่นๆ เจอ `*_PENDING`

มีได้ 2 กรณี

บอกให้ saga อื่นๆ ให้หยุด และ Retry ภายหลัง
- ทำง่ายสุด
- แต่ต้องให้ Service อื่นๆ มี Retry logic ด้วย
  - โค้ดจะเยอะมาก เพราะทุก Service ที่เกี่ยวข้องกับ saga เราจะต้องมี Retry logic
สั่ง saga อื่นๆ ให้รอ จนกว่าจะไม่ล็อค (ตัด _PENDING ทิ้งไปแล้ว)
- ถ้าเขียนไม่ดี = อาจจะเจอ Deadlock คือทุกๆ saga ต่างรอกันหมด

Commutative updates (การอัพเดตมีสมบัติสลับที่)

ทำให้การอัพเดตได้ผลลัพธ์เหมือนเดิมแม้นจะเปลี่ยนลำดับ ขอทำให้เห็นภาพแบบ A + B = B + A อะไรเทือกนั้น

วิธีนี้แก้ Lost update ได้

ตัวอย่างเช่น

Account มี Transaction คือถอนเงิน debit(), ฝากเงิน credit() (ไม่รวมการเช็คจำนวนเงินก่อนถอนเงิน) ไม่ว่าจะทำลำดับใดก็ได้ผลลัพธ์ดังเดิมเช่น 100 - 10 + 20 = 100 + 20 - 10

1
2
3
4
5


-- Commutative updates
-- debit() 200 bath
UPDATE accounts 
SET balance = balance - 200 
WHERE account_id = 'A001';

แบบนี้ Compensating transactions จะเกิดตอนไหนก็ได้เพียงแค่ credit() 200 บาทคืนไป

เรามาดูแบบที่ไม่เป็น Commutative updates กันบ้าง

1
2
3
4


-- Non-commutative updates
-- debit() 200 bath
-- Current balance = 1000 -> 1000 - 200 = 800
UPDATE accounts SET balance = 800 WHERE account_id = 'A001';

แบบนี้ผลลัพธ์จะไม่เท่ากันหากสลับลำดับ เช่น saga A และ saga B เริ่มอ่าน Balance = 1000 พร้อมกัน ต่อมา saga A เปลี่ยนค่าเป็น 800 (ถอน 200 บาท) และ saga B เปลี่ยนค่าเป็น 700 (ถอน 300 บาท) ตามลำดับ ผลจะกลายเป็น Balance = 700 แต่ถ้าสลับ saga B, A ผลลัพธ์จะกลายเป็น 800 บาท แต่ผลลัพธ์ที่ถูกควรเป็น Balance = 500

Pessimistic View (มองโลกในแง่ร้าย)

เรียงลำดับของ saga ใหม่ให้ลดปัญหา Dirty read ให้มากที่สุด

Cancel Order Saga

Consumer Service เพิ่มจำนวนยอดเงิน (Compensatable transactions)
Order Service เปลี่ยน state เป็น cancelled (Pivot transactions)
Delivery Service ยกเลิกการส่ง (Retriable transactions)

Delivery Service เป็นจุดเกิด Failure บ่อยๆ เช่น ไม่มีคนขับ

ทำไมแบบนี้จึงเกิด Dirty read ได้ง่าย เช่น เกิด Cancel Order Saga เพิ่มยอดเงินเป็น 200 บาทและ Create order saga อ่านค่า 200 บาทและลดจำนวนยอดเงินเป็น 150 บาท ต่อมา Cancel Order Saga เกิด Failure ที่ Delivery Service ยกเลิกการส่ง ทำให้เกิดการ Compensating transactions

แต่ปัญหาคือ Create order saga อ่านค่า 200 บาทไปแล้ว

Consumer Service จริงๆ มันไม่ควรเป็น Compensatable transactions เพราะหากถูกชดเชยจะทำให้คนอื่นเกิด Dirty read

Delivery Service ควรเป็น Pivot transactions เพราะมันพังบ่อยๆ

Pessimistic View จะแก้ลำดับ saga ใหม่เป็น

Order Service เปลี่ยน state เป็น cancelled (Compensatable transactions)
Delivery Service ยกเลิกการส่ง (Pivot transactions)
Consumer Service เพิ่มจำนวนยอดเงิน (Retriable transactions)

สังเกตว่า Consumer Service เพิ่มจำนวนยอดเงินเป็น Retriable transactions หมายความว่า saga ต้อง retry ไปเรื่อยๆ จนกว่าจะเพิ่มจำนวนยอดเงินสำเร็จ

Reread value (อ่านซ้ำสองรอบ)

การอ่านอีกรอบจะทำให้มั่นใจว่าไม่มีการเปลี่ยนแปลงเกิดขึ้นระหว่าง saga นั้นๆ

ป้องกัน Dirty read

Version File

ไม่ใช่ว่าทุกการอัพเดตจะเป็น Commutative ไม่ใช่ว่า A + B = B + A เสมอไป ถ้ามันไม่สามารถสลับที่ได้ เราจึงควรบันทึก Operation เพื่อให้เรียงลำดับใหม่ (Reorder) ใหม่ได้ดี

เช่น ระบบนี้ไม่มี Semantic lock (ไม่มีเช็ค *_PENDING)

ถ้ามีสอง saga A ทำ cancel() กับ saga B approve() ผลลัพธ์ควรได้ cancel

ถ้า saga B มาก่อน saga A ก็ดีไปได้ cancel
แต่ถ้า saga A มาก่อน saga B ผลดันได้ approve

หากทำ Version File ระบบจะบันทึกทุกๆ Operation และเห็นว่า saga A มาก่อนและจะข้าม saga B ทิ้งไป

By value (ตามมูลค่า/ความเสี่ยง)

ดูตามมูลค่าความเสี่ยง business risk

ความเสี่ยงต่ำ ให้ใช้ Saga เพื่อความรวดเร็วและ Scalability
- ประสิทธิภาพสูง แต่ปลอดภัยต่ำกว่า
ความเสี่ยงสูง ให้ใช้ Distributed Transactions (เช่น 2PC)
- ประสิทธิภาพต่ำ แต่ปลอดภัยสูงกว่า

← หน้าก่อนหน้า

ตอนถัดไป →

Microservice ตอนที่ 2 Inter process communication (IPC)

Fri, 03 Apr 2026 00:00:00 +0000

Inter process communication (การสื่อสารภายใน)

การสื่อสารระหว่าง Service นั้นเป็นหนึ่งในหัวใจหลักของ Microservice ทำให้เกิดการแลกเปลี่ยนข้อมูลซึ่งกันและกัน

ชนิดของ Inter process communication

แบ่งออกเป็น 2 ชนิดได้แก่

Synchronous remote procedure invocation
- ตัวอย่างเช่น gRPC, REST เป็นต้น
- Circuit breaker pattern
Asynchronous messaging
- ตัวอย่างเช่น Kafka, RabbitMQ เป็นต้น
- Message Broker pattern
- Outbox Pattern

Synchronous remote procedure invocation

Important Note 📝:

รอการตอบสนอง (Blocking)

Circuit breaker pattern

ลักษณะ

Blocking เมื่อ Client ทำการ Request ไปหา Server และจะถูก Block (ต้องรอ) จนกว่า Server
one-to-one สื่อสารได้แค่ 1 คู่เท่านั้น

ข้อดี

ไม่มีปัญหาจู้จี้จุกจิกเหมือน Asynchronous messaging
เหมาะสมงานที่ต้องการคำตอบทันที (Realtime) หรือความถูกต้องสูง

ข้อเสีย

High Coupling หากมี Service ไหนตายไป ตายทั้งระบบ (Cascading Failure) เพราะรอการ Response จาก Service ที่ตายไปนั้นเอง ซึ่งจะไม่มีการตอบกลับมา
สื่อสารได้แค่ one-to-one คุยเป็นคู่ๆ เท่านั้น

ประเด็นสำคัญ

gRPC ประหยัด Bandwidth มากกว่า REST
ต้องมีการกำหนด Timeout ของการ Request
- เพื่อป้องกัน Server ปลายทางตายแล้วต้นทางยังรอคนตาย
Circuit breaker pattern
- เพื่อป้องกัน Server ปลายทางตายแล้วต้นทางยังไปถามเรื่อยๆ
- Circuit breaker เปรียบเสมือนสะพานไฟ ไว้กันไฟฟ้าลัดวงจร (Short Circuit) ถ้าในบริบทนี้หมายถึงป้องกันปลายทางตาย
ถ้า Service มีหลายๆ Instance ต้องทำ Service Discovery
- Client-Side Discovery
- Server-Side Discovery

Circuit breaker pattern

เรามาลองดูว่ามีเรื่องอะไรที่ต้องรู้เกี่ยวกับ Circuit breaker pattern

มี Library จัดการเรื่องพวกนี้ให้
- เช่นใน golang มี hystrix-go เป็นต้น

stateDiagram-v2
 [*] --> Closed: เริ่มต้น
 
 Closed --> Open: Error บ่อยๆ เกิน Threshold
 
 Open --> HalfOpen: รอครบเวลา
 
 HalfOpen --> Open: ทดสอบแล้วยัง Error
 HalfOpen --> Closed: ทดสอบแล้ว Success

Closed สถานะวงจรปิด ทำให้ Request เกิดตามปกติไปหาปลายทาง
- หาก Error เกิดบ่อยเกินไปจะพาไปสู่สถานะ Open
Open สถานะวงจรเปิด สั่งปิดการ Request ไปหาปลายทาง
- รอเวลาสักพักเพื่อไปสู่สถานะ HalfOpen
HalfOpen ที่สถานะนี้จะเกิดได้ 2 กรณี
- ไปสู่ Closed เมื่อทดสอบแล้ว Success
- ไปสู่ Open เมื่อทดสอบแล้วยัง Error

Service Discovery

เมื่อเราอยาก Scale โดยการขยายจำนวน Instance ของ Service เช่น เปิด Service A 5 ตัว เมื่อนั้นให้รู้ไว้ว่าเราต้องทำสองกรณีนี้เสมอคือ

1. Client-Side Discovery

Service Registry เทคโนโลยีและเครื่องมือสำคัญที่นิยมใช้ เช่น Netflix Eureka, HashiCorp Consul
Client-Side Load Balancer & Client Libraries เทคโนโลยีและเครื่องมือสำคัญที่นิยมใช้ เช่น Spring Cloud LoadBalancer, OpenFeign

graph TD
 %% Nodes
 SR(Service Registry)
 Client[Client]
 
 subgraph Service_Pool [Service A Instances]
 S1[Service A #1]
 S2[Service A #2]
 S3[Service A #3]
 end

 %% Styles
 style Client fill:#9b59b6,stroke:#333,stroke-width:2px,color:#fff
 style SR fill:#e74c3c,stroke:#333,stroke-width:2px,color:#fff
 style S1 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff
 style S2 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff
 style S3 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff

 %% Flow
 S1 & S2 & S3 -- "Register" --> SR
 Client -- "1. Query Registry" --> SR
 SR -. "2.Service Address" .-> Client
 Client -- "3. Call Direct" --> S1

แต่ละ Instance ของ Service ต้อง register เข้า Service registry
Client ต้องเป็นคนถามไปหา Server ว่ามีบริการอยู่ไหนบ้างเอง?
Client ต้องเลือก Instance ที่จะไปเอง (Direct call)
- Client ต้องทำ Client-Side Load Balancing ด้วยตัวเอง เพื่อให้เลือกได้อย่างเหมาะสมที่สุด

2. Server-Side Discovery

graph TD
 %% Nodes
 Client[Client]
 LB(Load Balancer)
 SR(Service Registry)
 S1[Service A #1]
 S2[Service A #2]
 S3[Service A #3]

 %% Styles
 style Client fill:#9b59b6,stroke:#333,stroke-width:2px,color:#fff
 style LB fill:#2ecc71,stroke:#333,stroke-width:2px,color:#000
 style SR fill:#e74c3c,stroke:#333,stroke-width:2px,color:#fff
 style S1 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff
 style S2 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff
 style S3 fill:#3498db,stroke:#333,stroke-width:2px,color:#fff

 %% Steps
 S1 -- "register" --> SR
 S2 -- "register" --> SR
 S3 -- "register" --> SR
 
 Client -- "1. call service" --> LB
 
 LB <== "2. get address for service" ==> SR
 
 LB -- "3. call service" --> S1

แต่ละ Instance ของ Service ต้อง register เข้า Service registry
Client ติดต่อกับ Load balancer ของ Server
Load balancer จะเป็นผู้เลือก Instance ให้ Client

Important Note 📝:

Client-Side Discovery เลือกเอง

Server-Side Discovery ให้ Server เลือกให้

Asynchronous messaging

Important Note 📝:

ไม่รอการตอบสนอง (Non-blocking)

Message broker Pattern

Outbox Pattern

ลักษณะ

Non-blocking เมื่อ Client ทำการ Request ไม่ต้องรอ Response
สื่อสารแบบ one-to-one คุยเป็นคู่หรือ one-to-many คุยเป็นกลุ่มก็ได้
มีรูปแบบวิธีการสื่อสาร 2 รูปแบบ
- Direct message (การสื่อสารตรง) 👎
  - Service รู้จักกันตรงๆ
  - ข้อเสีย คือ High Coupling ไม่ต่างจากแบบ Synchronous remote procedure invocation เช่น Service A คุยกับ Service B หากรู้จักกันตรงๆ จะพึ่งพากันมาเกินไป หาก Service B ตายจะส่งข้อมูลไม่ได้
- Message broker (การสื่อสารผ่านคนกลาง) 👍
  - Service ไม่ได้รู้จักกันตรงๆ รู้จักแค่ Broker คนกลาง
  - ข้อดี คือ Loose coupling อิสระต่อกัน ไม่พึ่งพากัน

Message broker เป็นตัวเลือกที่ดีที่สุด

Message Broker

เป็นดั่งไปรษณีย์ส่งจดหมายไปยัง Service ต่างๆ

graph LR
 %% Nodes
 A[Service A]
 MB[Message Broker]
 B[Service B]
 C[Service C]
 D[Service D]

 %% Styles
 style A fill:#e1e1e1,stroke:#333,stroke-width:1px
 style MB fill:#e1e1e1,stroke:#333,stroke-width:1px
 style B fill:#e1e1e1,stroke:#333,stroke-width:1px
 style C fill:#e1e1e1,stroke:#333,stroke-width:1px
 style D fill:#e1e1e1,stroke:#333,stroke-width:1px

 %% Flow
 A -- "Publish" --> MB
 MB --> B
 MB --> C
 MB --> D

ข้อดี

Loose coupling แทบไม่ต้องพึ่งพากันเลย
Availability สูงกว่า เพราะหาก Service อื่นๆ ตายจะไม่พาเราตายไปด้วย
สื่อสารได้มากกว่า 1 คู่

ข้อเสีย

ปัญหาจู้จี้จุกจิกเยอะกว่า Synchronous remote procedure invocation

ปัญหา

Duplicated message บางครั้งอาจจะเกิดข้อความซ้ำส่งไป (รับมือได้ ✅)
Incorrect Message Ordering บางครั้ง Message อาจจะผิดลำดับ (แก้ได้ ✅)

ตัวอย่างเช่น Service A มี Instance คือ S1, S2 และมี Message คือ M1, M2 หากว่าการส่ง Message กระจายตัวเป็นดังนี้

M1 ไปหา S1

M2 ไปหา S2

มีความเป็นไปได้ที่ M2 จะไปถึงปลายทางก่อน M1 ทำให้การ Process ผิดลำดับไป

การ Update Database และการส่ง Message ไม่ Atomicity ทำให้เกิดเหตุการดังนี้ (แก้ได้ ✅)
- ส่งแต่ไม่ Update คือการ Update ดันได้ Error และ Rollback ไปแล้ว แต่ยังส่ง Message ไปบอกแล้วว่า Update สำเร็วแล้ว (ทั้งๆ ที่การ Update นั้นถูกยกเลิกไปแล้ว)
- Update แต่ไม่ส่ง คือการ Update สำเร็จ แต่ส่ง Message ไม่สำเร็จ อันนี้ปลายทางก็จะไม่รู้ว่า Update แล้ว

การแก้ปัญหา

การแก้ปัญหา Duplicated message

เราสามารถแก้ปัญหา Duplicated message ข้อความซ้ำได้โดยการบันทึก Message ID ของข้อความที่รับมาลง Database เพื่อให้ระบบรู้ว่าข้อความนี้เคยทำแล้วหรอไม่ ในกรณีที่มีข้อความใหม่มา โดยเราจะทำการบันทึกลง PROCESSED_MESSAGE table และอัพเดต Business Data Table ใน Transaction เดียวกัน

flowchart LR
 Msg[Message] --> App[Consumer App]
 subgraph DB [Database Transaction]
 App -->|1. Insert| T[PROCESSED_MSG table]
 App -->|2. Update| Biz[Business Data Table]
 end
 T -.->|Duplicate Key Error| Ignore[Ignore Message]

การแก้ปัญหา Incorrect Message Ordering

ปัญหานี้อาจจะพบเจอใน Tech อื่นๆ ได้บ้าง แต่ถ้าใช้ Kafka และ RabbitMQ พวกมันได้แก้ปัญหาพวกนี้ไปแล้ว

graph LR
 subgraph P [Sender Side]
 Sender[Sender] --> Router{Router /
Message Key}
 end

 subgraph Broker [Message Broker]
 direction TB
 subgraph P1 [Partition 1]
 M1[orderId = 1]
 end
 subgraph P2 [Partition 2]
 M2[orderId = 2]
 end
 subgraph P3 [Partition 3]
 M3[orderId = 3]
 end
 end

 subgraph C [Consumer Side]
 P1 --> Instance1[Service A
Instance 1]
 P2 --> Instance2[Service A
Instance 2]
 P3 --> Instance3[Service A
Instance 3]
 end

 Router -- "Hashing(orderId)" --> P1
 Router -- "Hashing(orderId)" --> P2
 Router -- "Hashing(orderId)" --> P3

 style P1 fill:#f9f,stroke:#333,stroke-width:2px
 style P2 fill:#f9f,stroke:#333,stroke-width:2px
 style P3 fill:#f9f,stroke:#333,stroke-width:2px

เนื่องจากปัญหาคือการกระจาย Message ไปยัง Instance ต่างๆ ของ Service ทำให้ข้อมูลผิดลำดับได้ถูกไหม? แล้วทางแก้ปัญหานั้นก็ง่ายแสนง่าย ก็คือให้ข้อความที่มี Partition key อันเดียวกันส่งไปที่ Instance เดียวกัน

Important Note 📝:

Partition คือท่อส่งข้อความไปหาปลายทาง

เช่น จากภาพเราใช้ Partition key เป็น OrderId ลองดูไปที่ OrderId = 1 ทุกๆ Message ที่มี OrderId = 1 จะไปอยู่ใน Partition 1 ตลอดในช่วงเวลานึง ทำให้รับประกันว่า Message จะเรียงลำดับข้อความถูกต้องเพราะไม่กระจายไปมั่วๆ

ต่อให้ Message ที่ OrderId คนละอันกันส่งแบบกระจาย Instance ต่างๆ ก็ไม่เป็นอะไร เพราะ Order คนละตัวกันไม่น่ามีผลต่อกัน สำคัญคือ Order เดียวกันส่งไปที่ Partition เดียวกันก็พอแล้ว

Important Note 📝:

Kafka จัดการเรื่องพวกนี้ให้แล้ว

การใช้งานพื้นฐาน Kafka

การแก้ปัญหาความไม่ Atomicity ของ Updating และ Messaging

เราจะใช้ Outbox Pattern ในการแก้ปัญหานี้ รูปจาก https://microservices.io/patterns/data/transactional-outbox.html

Important Note 📝:

โดยเราจะทำให้การ

Update, Insert, Delete ข้อมูล Business

Insert ข้อความที่จะส่งลงใน Outbox Table

ให้อยู่ใน Transaction เดียวกัน

และให้ Message Relay ไปอ่าน Outbox Table เพื่อส่งข้อความไปที่ Message broker

การใช้ Transaction เดียวกันทั้งการ CRUD และ Messaging ทำให้เกิด Atomicity นั้นเอง

การ Implementation ของ Message Relay มีด้วยกัน 2 รูปแบบ

Transaction Log Tailing (วิธีที่แนะนำ)
- Relay อ่าน Database Transaction Log (ดักจับ log)
Polling Publisher (วิธีแบบง่าย แต่เป็นภาระ Database)
- Relay อ่าน Query ตารางตรงๆ ทุกๆ x วินาที

บทสรุปของ Message broker

จัดการ Duplicated message, ความไม่ Atomicity ของ CRUD และ Messaging
1. การบันทึก Insert message id ลง Processed message table
2. การทำ CRUD ของ Business
3. การส่งข้อความ Messaging ต้อง Insert ลง Outbox table
- (1)-(3) ทั้งหมดที่กล่าวมานี้ต้องอยู่ใน Transaction เดียวกัน
Partition key ใช้ป้องกันข้อความผิดลำดับได้
Message Relay ทำได้ 2 วิธี แต่ดีที่สุดคือ Transaction Log Tailing

← หน้าก่อนหน้า

ตอนถัดไป →

Microservice ตอนที่ 1 Monolith vs Microservice

Mon, 30 Mar 2026 00:00:00 +0000

Monolith vs Microservice

Monolith

Monolith คือ Software pattern ที่รวมบริการทุกอย่างไว้ในที่ Repository เดียวกัน

graph TD
 subgraph Monolith_App [Monolithic Application]
 Auth[Auth Service]
 Order[Order Service]
 Pay[Payment Service]
 end
 Monolith_App --- DB[(Shared Database)]

ลักษณะ

ในระบบนี้จะใช้ 1 Database เท่านั้น ทุกๆ บริการจะอยู่ใน Database ตัวนี้
บริการทุกอันอยู่ใน Repository เดียวกัน
หลายๆ บริการสามารถอยู่ใน Transaction เดียวกันได้ เนื่องจากยังไงก็มีแค่ 1 Database

ข้อดี

จัดการ Transaction ง่ายเนื่องจากมีแค่ 1 Database (ACID)
Deploy ง่ายแค่เพราะมีแค่ก้อนๆ เดียว
Develop ง่ายๆ กว่าในช่วงแรกๆ ที่ระบบไม่ใหญ่มาก

ข้อเสีย

Maintenance ยากหากระบบใหญ่ขึ้นมาก ใช้เวลานานในการเพิ่ม หรือแก้ไข
การ Testing ทำได้ยากตอนที่ระบบใหญ่และใช้เวลานานมาก
ต้องบังคับใช้ Tech stack เดียวกันทั้งระบบ
- ในขณะที่ Microservice สามารถแยก Tech stack ตามแต่ละบริการ

Microservice

คือ Software pattern ที่เขียนระบบเป็นบริการแยกๆ กันเป็น Service ที่มีหน้าที่เฉพาะของตนและเป็นอิสระต่อกันโดยสิ้นเชิง

graph TD
 User((User)) --> Gateway[API Gateway]

 subgraph Auth_System [Auth Microservice]
 Auth[Auth Service] --- DB1[(Auth DB)]
 end

 subgraph Order_System [Order Microservice]
 Order[Order Service] --- DB2[(Order DB)]
 end

 subgraph Pay_System [Payment Microservice]
 Pay[Payment Service] --- DB3[(Payment DB)]
 end

 Gateway --> Auth
 Gateway --> Order
 Gateway --> Pay

 Order -.-> |การสื่อสารภายใน| Pay

ลักษณะ

แต่ละ Service มี Database เป็นของตนเองและแยกกับ Service อื่นๆ
แต่ละ Service มี Transaction แยกกัน เพราะอยู่กันคนละ Database
ต้องมีการสื่อสารภายในระหว่าง Services
แต่ละ Service มี Tech stack เป็นของต้นเองได้
แต่ละ Service แยกกัน Deployment ได้อิสระ

ข้อดี

พอระบบใหญ่ๆ จะ Maintenance ได้ง่ายกว่า Monolith มากๆ
Service เป็นอิสระต่อกันทำให้
- แยกกันพัฒนาได้โดยแบ่งเป็นทีมเล็ก
- แต่ละ Service เลือกใช้ Tech stack เป็นของตนเองได้
- แยกกันได้ Deploy ตามแต่ละ Service
ทดสอบง่ายเนื่องจากแยก Service ออกมาเป็นเล็กๆ ทำให้
- ทดสอบได้เร็วและใช้เวลาน้อยกว่า Monolith
- ทดสอบได้ง่ายกว่า Monolith

Microservice ไม่ใช่ยาวิเศษรักษาทุกโรค

ใช่ว่าจะดีกว่า Monolith เสมอไป!

ข้อเสีย

ถ้าระบบไม่ใหญ่(ระบบเล็กๆ) Monolith จะดีกว่า
จัดการ Transaction ยากกว่า เพราะมีหลายๆ Databases (เดี๋ยวเรียนรู้ใน SAGA Pattern)

← หน้าก่อนหน้า

ตอนถัดไป →

Blogs on Nextjingjing

Microservice ตอนที่ 4 Queries in Microservice

การทำ Query ใน Microservice

ประเภทของการทำ Query Microservice

API composition pattern

ลักษณะ

ข้อดี

ข้อเสีย

Command query responsibility segregation (CQRS) pattern

ทำไมต้องใช้ CQRS ?

ลักษณะ

ข้อดี

ข้อเสีย

คำแนะนำ

การ Implement ของ CQRS

การเลือก Database ของฝั่ง Query

ป้องกัน Duplicated messages

ป้องกัน Inconsistency

ป้องกัน Concurrency ใน Record เดียวกัน

Microservice ตอนที่ 3 saga pattern

การจัดการกับ Transaction ด้วย saga pattern

ก่อนมี saga Pattern

saga Pattern

ลักษณะ

ข้อดี

ข้อเสีย

ปัญหา

Compensating transactions

ลำดับของการชดเชย

บาง Transaction อาจจะไม่จำเป็นต้องเกิดการชดเชย

โครงสร้างของ saga

Implementation ของ saga pattern

ประเภทของ saga pattern

Choreography-based sagas

ลักษณะ

ข้อดี

ข้อเสีย

Orchestration-based sagas

ลักษณะ

ข้อดี

ข้อเสีย

คำแนะนำ

การรับมือกับการขาด Isolation ของ ACID ใน saga pattern

ปัญหา

การแก้ปัญหา

Semantic lock

เมื่อ saga อื่นๆ เจอ *_PENDING

Commutative updates (การอัพเดตมีสมบัติสลับที่)

Pessimistic View (มองโลกในแง่ร้าย)

Reread value (อ่านซ้ำสองรอบ)

Version File

By value (ตามมูลค่า/ความเสี่ยง)

Microservice ตอนที่ 2 Inter process communication (IPC)

Inter process communication (การสื่อสารภายใน)

ชนิดของ Inter process communication

Synchronous remote procedure invocation

ลักษณะ

ข้อดี

ข้อเสีย

ประเด็นสำคัญ

Circuit breaker pattern

Service Discovery

1. Client-Side Discovery

2. Server-Side Discovery

Asynchronous messaging

ลักษณะ

Message Broker

ข้อดี

ข้อเสีย

ปัญหา

การแก้ปัญหา

การแก้ปัญหา Duplicated message

การแก้ปัญหา Incorrect Message Ordering

การแก้ปัญหาความไม่ Atomicity ของ Updating และ Messaging

บทสรุปของ Message broker

Microservice ตอนที่ 1 Monolith vs Microservice

Monolith vs Microservice

Monolith

ลักษณะ

ข้อดี

เมื่อ saga อื่นๆ เจอ `*_PENDING`