Design Technique for Enterprise Transaction Design

สรุปแนวคิดสำหรับการออกแบบระบบให้ระบบขนาดใหญ่ (Enterprise) และรองรับข้อมูลธุรกรรม(Transaction) จำนวนมาก โดยต้องการให้ขยายระบบ(Scalability) ได้ในอนาคตครับ

เลือกรูปแบบ Data Modeling

- Transaction

• การ Lock แบบ Coarse-Grained Lock ไปทำที่ระดับ App ซะ เพราะ Database ทุกคนใช้ ถ้าไป Lock ก็กระทบชาวบ้าน และถ้าทำที่ App สามารถ Scale ได้
• ส่วนจะดูว่าใช้แนวคิดไหนในการ Lock มันมีพวก Architectural Tactic ช่วยอยู่แล้ว อย่างในตัว POSA3 มีพวกจัดการ Resource เช่น FIFI / LIFO หรือ Deadline Monotonic Scheduling เป็นต้น
• ถ้าทำ Lock แล้วแยกเป็น App Server อีกตัว ถ้ากลัวล่ม ก็ทำ Cluster สิ แล้ว จริงมันมีพวก Enterprise Integration Pattern อย่าง Service Grid เข้ามาช่วยครับ ^__^
• Lock มีหลายแบบอีก เช่น
  - Local
  - Distribute - ยุคก่อนจะเป็นตัว 2-Phase Commit ถ้าตอนนี้เป็นพวก SAGA Pattern
• การที่เราจัดลำดับ ความสัมพันธ์ของ Transaction ได้ ให้วาด State Diagram หรือ พวก BPMN ออกมาก่อน จะได้เห็นการไหลของ Data

- ORM vs ER

• ORM เน้น Denormalization ถ้าจะออกแบบเริ่มที่ Class Diagram ก่อน แล้วค่อยแปลงกลับไปเป็น ER Diagram เพราะปัญหาจุกจิ เช่นการ Lock
• ตั้งชื่อ Data Schema ให้สอดคล้องกับ Class (จริงถ้ามันไม่ตรงก็มี feature mapping นะ อย่างใน Dapper มี Attribute Column ด้วยนะ เพราะถ้ามี Mapping หมายความว่าต้องมี Cost ที่เสียไปสำหรับการหาว่า Class นี้ใช้กับ Database Column ไหน

- พวก Sensitive Data จัดการอย่างไร

• แยก Table ออกไป - จัดได้คุมสิทธิ์ได้ง่าย เช่น Table ข้อมูลลูกค้า กับ Table ข้อมูลบัตรเครคิด
• แล้ว Table ที่แยกไป จัดให้อยู่ในพื้นที่ที่เหมาะสม เช่นไว้ใน Database ที่อยู่ใน Security Zone คนละชั้นสื
• การจัดการข้อมูล INSERT / UPDATE ต้องเข้ารหัสแบบ One-way
• ออกแบบอย่างไง - ง่ายๆตาม Security Policy ของลูกค้า

- Data distribution / Data Centralization

• ข้อมูลลูกค้า มีกี่ระบบก็ของใครของมัน ช้อมูลไม่ Sync เอามา Sync สำหรับทำ Data Science พอต้องการเอาข้อมูลมาวิเคราะห์ก็ลำบากมากต้องเสียเวลามารวมข้อมูลอีก
• ทำเป็น API สิ นั้นแหละ Microservice

เลือกรูปแบบ Architectural Patterns

การเลือก Architecture ต้องดูจาก

• Quality Attribute (พวก -bility เช่น Scalability / Reliability / Availability เป็นต้น)
• Resource Constraint
• Transaction/Data Flow - Unit of Work
• Cost เรื่องเงินๆทองแหละครับ

- Resource Handings (POSA-3)

ตรงนี้จะเห็นว่า กล่องสีๆ พวก Performance / Scalability คือ พวก Quality Attribute โดยการเอา Pattern (กรอบประ) แต่ละอันมาช่วยเสริม อันไหน เช่น

• Caching เสริมพวก Performance / Scalability ตอนนี้ใช้ๆพวก Redis / Memcache
• Pooling ต้องการให้ Resouce มันแชร์กัน ไม่มีใครถือนานจะเกินไป เช่น Database Connection หรือ มองภาพใหญ่ Load Balance มัน Pool ให้เข้าแต่ละ Resource ให้เท่าๆกัน แต่ถ้าเต็มหมด ต้อง Scale เพิ่ม จาก Stat ที่เคยเก็บเอามา Predict
• Coordinator - ทำให้ได้ทั้ง ACID ขึ้นมา แต่อาจจะไม่ Strong เท่า DB และ Scale ได้ พวก 2-Phase Commit / Microservice SAGA Pattern
• Lookup - บอกว่าควรหา Resource จากไหน ที่ผมเคยใช้ อาจจะเป็น API ให้มา register ว่าทำอะไรได้บ้าง เวลามี Request เข้ามา ตัว Coordinator จะได้จัดการได้ต่อ ตอนนี้น่าจะเป็น Service Registry / Service Discovery
• Acquisition Pattern - อะไรที่ควรใช้ทันที (Eager) / รอได้ (Lazy / Partial) ตัวอย่างที่ชัดน่าจะพวก ORM ตอนที่ดึงหลาย Model หรือ พวก Dependency Injection

- Resource Management (POSA-2)

มีหลายอันเลยครับ ที่มาช่วยในเรื่องต่างๆ

Service Access and Configuration

• Wrapper Facade - Design Pattern พวก Adapter / Facade ไม่ให้ระบบคุยตรงๆ เช่น ต่อ API 3rd Party ให้มี ตัวคั่นกลาง
• Component Configurator - Runtime Config เช่น พวก Spring Bean หรือ Feature Toggle
• Interceptor - Inject ของเมื่อต้องการใช้ ที่ผมเคยเขียน Code จะเป็นพวก Castle.Core / ถ้าใช่ขึ้นพวก Firewall / API Gateway
• Extension Interface - ผมนึกถึง OOP นะ Class ที่มีหลาย Interface มาเพิ่มความสามารถ ถ้า Infra น่าจะพวก Side-Car

Event Handling

• Reactor - นึกถึงพวก socker พวก Chat App แยกกันยังไง ระหว่างเส้นทาง
• Proactor - web server ก็ได้นะ รับ request แล้วส่งต่อให้ตัวที่เกี่ยวข้องทำงาน
• Asynchronous Completion Token
• Acceptor-Connector

Synchronization

• Scoped Locking - เลือกจุดที่เหมาะสม การเปิด Transaction Begin-End
• Strategized Locking - กำหนด parameter ลองนึกถึงพวก Transaction Level เช่น Optimistic (แง่ร้าย Lock Write-Allow Read) / Pessimistic (แง่ดี Full Lock Read-Write) / Defer State - ทำก่อนจบ หรือ เมื่อเข้าเงื่อนไข
• Thread-Safe Interface - กันการเกิด Deadlock
• Double-checked locking

Concurrency

• Active Object
• Monitor Object - Lock ให้มี Thread เดียวที่จำเป็นทำงานอยู่
• Half-Sync/Half-Async - ตัวอย่างที่ชัด Message Queue พวก Kafka / RabbitMQ ที่ช่วยให้งาน Sync และ Async ทำงานได้อย่างมีประสิทธิภาพ และทำงาน Concurrent ได้
• Leader/Followers - Master-Slave / Map-Reduce
• Thread-Specific Storage - ให้แต่ละ Thread มี Resource ของตัวเอง พวก Storage พอเดา Web API / Blob

LAST UPDATE: 2022-10

Reference

• Pattern-Oriented Software Architecture
• https://www.dre.vanderbilt.edu/~schmidt/POSA-tutorial.pdf