Examples and Use Cases (ตัวอย่างและกรณีการใช้งาน)

space-based architecture เหมาะอย่างยิ่งสำหรับแอปพลิเคชันที่ประสบกับ spike สูงของ user หรือ request volume และแอปพลิเคชันที่มี throughput เกิน 10,000 concurrent user เราจะมาดู use case ของ space-based architecture สองแบบในที่นี้ คือแอปพลิเคชันจองตั๋วคอนเสิร์ตออนไลน์และระบบประมูลออนไลน์ ทั้งสองต้องการ performance, scalability และ elasticity ระดับสูง

Concert Ticketing System (ระบบจองตั๋วคอนเสิร์ต)

ระบบจองตั๋วคอนเสิร์ตเป็น problem domain ที่มีเอกลักษณ์เฉพาะ ตรงที่ concurrent user volume ค่อนข้างต่ำ จนกว่าจะมีการประกาศคอนเสิร์ตยอดนิยม เมื่อตั๋วสำหรับศิลปินที่ได้รับความนิยมเป็นพิเศษเปิดขาย user volume มักพุ่งขึ้นจากหลักร้อย concurrent user ไปเป็นหลักพันหรือแม้แต่หลักหมื่น ขึ้นอยู่กับคอนเสิร์ต นั้น ๆ โดยทุกคนต่างพยายามแย่งที่นั่งดี ๆ! ตั๋วมักขายหมดภายในไม่กี่นาที ดังนั้นระบบเหล่านี้จึงต้องการ characteristic ที่ space-based architecture รองรับอย่างแท้จริง

ระบบประเภทนี้มีความท้าทายมากมาย ก่อนอื่น มีจำนวนตั๋วทั้งหมดที่จำกัด ไม่ว่าจะเลือกที่นั่งแบบไหนก็ตาม ความพร้อมใช้งานของที่นั่งต้องถูกอัปเดตอย่างต่อเนื่องและรวดเร็วที่สุดเท่าที่จะทำได้ เนื่องจากมี concurrent request จำนวนมาก การเข้าถึง central database แบบ synchronous อย่างต่อเนื่องไม่น่าจะได้ผล— มันจะยากมากสำหรับฐานข้อมูลทั่วไปในการรองรับ concurrent request หลักหมื่นผ่าน standard transaction ที่ scale และความถี่ในการอัปเดตระดับนี้

space-based architecture จะเหมาะกับระบบจองตั๋วคอนเสิร์ต เนื่องจากความต้องการ elasticity สูง deployment manager จะรับรู้ถึงการเพิ่มขึ้นอย่างฉับพลันของจำนวน concurrent user ได้ทันที และ start processing unit จำนวนมากเพื่อรองรับ ticket purchase request ปริมาณมาก ในสภาพที่เหมาะสมที่สุด deployment manager สามารถถูก config ให้ start processing unit ในจำนวนที่จำเป็นก่อนที่ตั๋วจะเปิดขายไม่นาน ก่อน เพื่อให้พร้อม standby ก่อนที่ user load จะเพิ่มขึ้นอย่างมาก

Online Auction System (ระบบประมูลออนไลน์)

ระบบประมูลออนไลน์ (เว็บไซต์สำหรับประมูลสินค้า เช่น eBay) มี characteristic หลายอย่างที่คล้ายกับระบบ จองตั๋วคอนเสิร์ตออนไลน์ที่เราเพิ่งอธิบายไป ทั้งสองต้องการ performance และ elasticity ระดับสูง และ ทั้งสองมี spike ของ user และ request load ที่คาดเดาไม่ได้ เมื่อการประมูลเริ่มขึ้น ไม่มีทางรู้ได้เลย ว่าจะมีคนเข้าร่วมกี่คน หรือจะมี concurrent bid กี่ครั้งสำหรับแต่ละราคาที่เสนอ

space-based architecture เหมาะกับ problem domain นี้มาก เพราะช่วยให้สามารถ start processing unit หลายตัวได้เมื่อ load เพิ่มขึ้น แล้วทำลายทิ้งเมื่อการประมูลใกล้จบและไม่จำเป็นอีกต่อไป processing unit แต่ละตัวสามารถอุทิศให้กับการประมูลแต่ละครั้งได้ เพื่อรับประกัน consistency ของข้อมูลการประมูล นอกจากนี้ ธรรมชาติแบบ asynchronous ของ data pump หมายความว่าข้อมูลการประมูลสามารถถูกส่งไปยังกระบวน การอื่น ๆ (เช่น bid history, bid analytics และ auditing) ได้โดยไม่มี latency มากนัก ซึ่งเพิ่ม performance โดยรวมของกระบวนการประมูล

space-based architecture เป็น architectural style ที่ซับซ้อนแต่ทรงพลังมาก มันเป็น architectural style เดียวที่เพิ่ม responsiveness, scalability และ elasticity ร่วมกันให้สูงสุด ซึ่งส่วนใหญ่มาจาก วิธีที่มันใช้ caching และการไม่เข้าถึงฐานข้อมูลโดยตรง ด้วยเหตุนี้ มันจึงถือเป็น architectural style เฉพาะทาง ที่ใช้ในสถานการณ์ที่ต้องเพิ่ม architectural characteristic เฉพาะเหล่านี้ให้สูงสุด .

1 มันอาจมีข้อยกเว้นสำหรับกฎนี้ ขึ้นอยู่กับ implementation ของ caching product ที่ใช้ caching product บางตัว ต้องการ external controller เพื่อ monitor และควบคุมการ replicate ข้อมูลระหว่าง processing unit แต่ส่วน ใหญ่กำลังเลิกใช้โมเดลนี้แล้ว