04 มิ.ย. 2568·3 นาที
ทำไมการสเกลแนวนอนถึงยากกว่าการสเกลแนวตั้ง
การสเกลแนวตั้งมักแค่เพิ่ม CPU/RAM แต่การสเกลแนวนอนต้องการการประสาน งานแบ่งข้อมูล ความสอดคล้อง และงานปฏิบัติการมากขึ้น—นี่คือเหตุผลที่มันยากกว่า
การสเกลแนวตั้งมักแค่เพิ่ม CPU/RAM แต่การสเกลแนวนอนต้องการการประสาน งานแบ่งข้อมูล ความสอดคล้อง และงานปฏิบัติการมากขึ้น—นี่คือเหตุผลที่มันยากกว่า
การสเกลหมายถึง “รับมือกับปริมาณมากขึ้นโดยไม่ล้มเหลว” ปริมาณที่ว่านี้อาจเป็น:
เมื่อคนพูดถึงการสเกล พวกเขามักพยายามปรับปรุงหนึ่งหรือมากกว่านี้:
ส่วนมากจะกลับมาที่ธีมเดียว: การสเกลแนวตั้งรักษาความรู้สึกว่าเป็น “ระบบเดียว” ในขณะที่ การสเกลแนวนอนเปลี่ยนระบบของคุณให้เป็นกลุ่มเครื่องจำนวนหนึ่งที่ต้องประสานงานกัน — แล้วการประสานงานนี่แหละที่ทำให้ความยากเพิ่มขึ้นอย่างมาก
การสเกลแนวตั้งหมายถึงการทำให้เครื่องหนึ่งเครื่องแข็งแรงขึ้น คุณยังคงสถาปัตยกรรมเดิม แต่เพิ่มสเปกของเซิร์ฟเวอร์ (หรือ VM): เพิ่มคอร์ CPU, เพิ่ม RAM, ดิสก์เร็วขึ้น หรือแบนด์วิดท์เครือข่ายสูงขึ้น
คิดเหมือนการซื้อรถบรรทุกคันใหญ่ขึ้น: ยังคงมีคนขับคนเดียวและยานพาหนะหนึ่งคัน แต่ขนของได้มากขึ้น
การสเกลแนวนอนหมายถึงการเพิ่มเครื่องหรืออินสแตนซ์หลายตัวและแบ่งงานระหว่างพวกมัน — มักอยู่หลัง load balancer แทนที่จะมีเซิร์ฟเวอร์ตัวเดียวที่ทรงพลัง คุณจะรันเซิร์ฟเวอร์หลายตัวที่ทำงานร่วมกัน
เหมือนการใช้รถบรรทุกหลายคัน: ขนของได้มากขึ้นโดยรวม แต่คุณต้องจัดการตาราง เส้นทาง และการประสานงาน
สาเหตุทั่วไปได้แก่:
ทีมมักสเกลแนวตั้งก่อนเพราะเร็ว (อัพเกรดเครื่อง) แล้วสเกลแนวนอนเมื่อเครื่องหนึ่งถึงขีดจำกัดหรือเมื่อต้องการความพร้อมใช้งานสูง สถาปัตยกรรมที่โตแล้วมักผสมกัน: โหนดที่ใหญ่ขึ้นและจำนวนโหนดที่มากขึ้น ขึ้นกับคอขวดที่เจอ
การสเกลแนวตั้งน่าสนใจเพราะมันเก็บระบบไว้ที่ที่เดียว กับโหนดเดียวคุณมักมีแหล่งข้อมูลสถานะเดียวทั้งในหน่วยความจำและสถานะท้องถิ่น กระบวนการหนึ่งเป็นเจ้าของแคชในหน่วยความจำ คิวงาน ช่วงเซสชัน (ถ้าเก็บในหน่วยความจำ) และไฟล์ชั่วคราว
บนเซิร์ฟเวอร์เดียว งานปฏิบัติการส่วนใหญ่ตรงไปตรงมาเพราะแทบไม่มีการประสานงานระหว่างโหนด:
เมื่อสเกลขึ้น คุณดึงคันโยกที่คุ้นเคย: เพิ่ม CPU/RAM, ใช้สตอเรจที่เร็วขึ้น, ปรับดัชนี, จูนคิวรีและการตั้งค่า คุณไม่ต้องออกแบบการกระจายข้อมูลหรือวิธีให้หลายโหนดยอมกันใน "ขั้นตอนต่อไป"
การสเกลแนวตั้งไม่ใช่ “ฟรี” — แต่มันเก็บความซับซ้อนไว้ในที่เดียว
สุดท้ายคุณจะเจอขีดจำกัด: อินสแตนซ์ที่ใหญ่ที่สุดที่เช่าได้, ผลตอบแทนที่ลดลง, หรือค่าใช้จ่ายพุ่งสูง คุณยังเสี่ยงต่อ downtime มากขึ้น: ถ้าเครื่องใหญ่ล้ม ระบบส่วนใหญ่จะล่มด้วย เว้นแต่คุณจะเพิ่ม redundancy
เมื่อคุณสเกลออก คุณไม่ได้ได้แค่ "เซิร์ฟเวอร์เยอะขึ้น" แต่ได้ผู้แสดงอิสระหลายคนที่ต้องตกลงกันว่าใครรับผิดชอบงานใด เวลาใด และใช้ข้อมูลใด
บนเครื่องเดียว การประสานงานมักเป็นไปโดยปริยาย: หน่วยความจำเดียว กระบวนการเดียว สถานที่เดียวให้ค้นหาสถานะ ในหลายเครื่อง การประสานงานกลายเป็นฟีเจอร์ที่ต้องออกแบบ
รูปแบบและเครื่องมือที่พบได้บ่อย:
บั๊กการประสานงานมักไม่แสดงเป็นการล่มชัดเจน มักเห็นเป็น:
ปัญหาเหล่านี้มักโผล่เมื่อมีโหลดจริง ระหว่างการ deploy หรือเมื่อเกิดความล้มเหลวบางส่วน ระบบดูปกติก็ต่อเมื่อไม่ได้ทดสอบภายใต้ความเครียด
เมื่อสเกลออก คุณมักไม่สามารถเก็บข้อมูลทั้งหมดไว้ที่เดียวได้ คุณต้องแบ่งข้อมูลข้ามเครื่อง (shard) เพื่อให้หลายโหนดเก็บและให้บริการพร้อมกัน การแบ่งนี่เองเป็นจุดเริ่มต้นของความซับซ้อน: ทุกการอ่านและเขียนขึ้นกับว่า "เรคอร์ดนี้อยู่ชาร์ดไหน?"
Range partitioning จัดกลุ่มข้อมูลตามคีย์ที่เรียงลำดับได้ (เช่น ผู้ใช้ A–F อยู่ชาร์ด 1, G–M อยู่ชาร์ด 2) ตรรกะเข้าใจง่ายและรองรับการค้นหาแบบช่วงดี แต่โหลดไม่เท่ากัน: ถ้าช่วงหนึ่งเป็นที่นิยม ชาร์ดนั้นจะกลายเป็นคอขวด
Hash partitioning เอาคีย์ไปรันผ่านฟังก์ชันแฮชแล้วกระจายผลไปยังชาร์ดต่าง ๆ กระจายทราฟฟิกได้สม่ำเสมอขึ้น แต่การค้นหาแบบช่วงทำได้ยากเพราะเรคอร์ดที่เกี่ยวข้องกระจายกัน
เพิ่มโหนดและคุณอยากใช้มัน — แปลว่าข้อมูลต้องย้าย ลดโหนดหรือโหนดล้มก็ต้องให้ชาร์ดอื่นรับช่วงต่อ การรีบาลานซ์อาจทำให้เกิดการถ่ายโอนข้อมูลขนาดใหญ่ การอุ่นแคช และการลดประสิทธิภาพชั่วคราว ในช่วงย้าย คุณยังต้องป้องกันการอ่านข้อมูลเก่าและการเขียนผิดเส้นทาง
แม้แต่อัลกอริธึมแฮชก็ไม่รับประกันการกระจายสมบูรณ์ ทราฟฟิกจริงไม่เท่ากัน บัญชีที่มีคนตามมาก ผลิตภัณฑ์ฮิต หรือรูปแบบการเข้าถึงตามเวลา อาจทำให้การอ่าน/เขียนกระจุกตัวในชาร์ดเดียว ชาร์ดร้อนสามารถจำกัดทั้งระบบได้
ชาร์ดนำภาระงานต่อเนื่อง: รักษากฎการ route, รัน migration, ทำ backfill หลัง schema change, และวางแผน split/merge โดยไม่ทำลายลูกค้า
เมื่อสเกลออก คุณไม่ได้เพิ่มแค่เซิร์ฟเวอร์ แต่เพิ่มสำเนาของแอป ความยากคือสถานะ: สิ่งที่แอป "จำ" ระหว่างคำขอหรือระหว่างที่งานกำลังทำ
ถ้าผู้ใช้ล็อกอินกับ Server A แต่คำขอต่อไปไปที่ Server B, B รู้หรือไม่ว่าเป็นใคร?
แคชเร่งความเร็ว แต่หลายเซิร์ฟเวอร์หมายถึงหลายแคช ปัญหาที่ตามมาคือ:
ด้วย worker หลายตัว งานแบ็กกราวด์อาจรันซ้ำเว้นแต่จะออกแบบไว้ เช่น ใช้คิว, เช่า/ล็อก, หรือทำงานให้ idempotent เพื่อไม่ให้ "ส่งใบแจ้งหนี้" หรือ "คิดบัตร" สองครั้ง โดยเฉพาะในช่วง retry และ restart
กับโหนดเดียว (หรือฐานข้อมูล primary เดียว) มักมีแหล่งความจริงชัดเจน เมื่อสเกลออก ข้อมูลและคำร้องกระจายไปหลายเครื่อง การทำให้ทุกคนเห็นข้อมูลเดียวกันจึงเป็นความกังวลต่อเนื่อง
Eventual consistency มักเร็วกว่าหรือราคาถูกกว่าที่ขนาดใหญ่ แต่ทำให้เกิดมุมเงื่อนแปลก ๆ ได้
ปัญหาทั่วไปรวมถึง:
คุณไม่สามารถกำจัดความล้มเหลวได้ แต่สามารถออกแบบให้รับมือได้:
ธุรกรรมข้ามบริการ (order + inventory + payment) ต้องให้หลายระบบตกลงกัน ถ้าขั้นตอนหนึ่งล้มคราวกลางทาง คุณต้องมี action ชดเชยและบันทึกอย่างระมัดระวัง พฤติกรรม "ทั้งหมดหรือไม่มีเลย" ยากเมื่อเครือข่ายและโหนดล้มแยกกัน
ใช้ความสอดคล้องเข้มงวดสำหรับสิ่งที่ต้องถูกต้อง: การชำระเงิน ยอดบัญชี จำนวนสต็อก การจองที่นั่ง ส่วนข้อมูลที่ไม่สำคัญมาก (analytics, recommendation) มักยอมรับ eventual consistency ได้
เมื่อสเกลขึ้น การเรียกภายในโปรเซสที่เคยเร็วและคาดเดาได้ กลายเป็นการเรียกผ่านเครือข่าย — เพิ่มความหน่วง ความแปรปรวน และโหมดความล้มเหลวที่โค้ดต้องจัดการ
การเรียกผ่านเครือข่ายมี overhead คงที่ (serialization, คิว, hops) และ overhead ผันแปร (ความแออัด เส้นทาง เพื่อนบ้านเสียงดัง) แม้ค่าเฉลี่ยจะโอเค แต่ tail latency (ช้าที่สุด 1–5%) อาจครอบงำ UX เพราะการพึ่งพาช้าเพียงตัวเดียวอาจกั้นคำร้องทั้งหมด
แบนด์วิดท์และการสูญหายของแพ็กเกตก็เป็นข้อจำกัด: ที่อัตราคำร้องสูง payload เล็ก ๆ สะสม และการส่งซ้ำเพิ่มโหลดโดยเงียบ ๆ
หากไม่มี timeout การเรียกช้า ๆ จะสะสมและเธรดติดค้าง กับ timeout และ retry คุณอาจฟื้นตัวได้ — จนกว่า retry จะเพิ่มโหลด
รูปแบบความล้มเหลวทั่วไปคือ retry storm: backend ช้าลง ลูกค้าหมดเวลาแล้ว retry, retry เพิ่มโหลด backend ทำให้ช้าขึ้นอีก
การ retry ที่ปลอดภัยมักต้องมี:
เมื่อติดตั้งหลายอินสแตนซ์ ลูกค้าต้องรู้ว่าจะส่งไปที่ไหน — ผ่าน load balancer หรือ service discovery พร้อม client-side balancing ไม่ว่าจะทางใด คุณเพิ่มชิ้นส่วนที่เคลื่อนไหว: health checks, draining การเชื่อมต่อ, การแจกจราจรไม่สม่ำเสมอ และความเสี่ยงส่งคำขอไปยังอินสแตนซ์ที่ครึ่งๆ เสีย
เพื่อป้องกันไม่ให้การโอเวอร์โหลดแพร่กระจาย คุณต้องมี backpressure: คิวที่มีขอบเขต, circuit breakers, และ rate limiting เป้าหมายคือล้มอย่างรวดเร็วและทำนายได้ แทนที่จะปล่อยให้ความช้าตัวเล็ก ๆ กลายเป็นเหตุการณ์ระบบใหญ่
การสเกลแนวตั้งมักล้มในแบบชัดเจน: เครื่องใหญ่ตัวเดียวยังเป็นจุดเดียว หากมันช้าหรือ crash ผลกระทบเห็นได้ชัด
การสเกลแนวนอนเปลี่ยนสมการ ด้วยหลายโหนด ปกติที่จะมีบางเครื่องไม่แข็งแรงขณะที่อื่น ๆ ปกติ ระบบยัง "ขึ้น" แต่ผู้ใช้เห็นข้อผิดพลาด หน้าช้า หรือพฤติกรรมไม่สอดคล้อง นี่คือ partial failure และกลายเป็นสภาพปกติที่คุณต้องออกแบบรับมือ
ในสถาปัตยกรรมสเกลออก บริการพึ่งพาบริการอื่น: DB, cache, queue, API ภายนอก ปัญหาเล็กน้อยสามารถกระจาย:
เพื่อรอดพ้นความล้มเหลวบางส่วน ระบบเพิ่มความซ้ำซ้อน:
สิ่งนี้เพิ่มความพร้อมใช้งาน แต่เพิ่ม edge cases: split-brain, replica เก่า, และการตัดสินใจเมื่อไม่ถึง quorum
รูปแบบที่ใช้บ่อยรวม:
กับเครื่องเดียว เรื่องราวของระบบอยู่ที่เดียว: ล็อกเดียว กราฟ CPU เดียว กระบวนการเดียวให้ตรวจสอบ ด้วยการสเกลแนวนอน เรื่องราวกระจาย
ทุกโหนดเพิ่มสตรีมของล็อก เมตริก และแทรซ การยากไม่ใช่การเก็บข้อมูล แต่การเชื่อมโยงข้อมูลเหล่านั้น เหตุผิดพลาดอาจเริ่มที่เว็บโหนด เรียกสองบริการ ตีแคช และอ่านจากชาร์ดเฉพาะ ทำให้เบาะแสกระจัดกระจายและลำดับเวลาไม่ตรงกัน
Distributed tracing เหมือนติดหมายเลขติดตามให้คำร้อง รหัส correlation เป็นหมายเลขนั้น ส่งต่อผ่านบริการและใส่ในล็อกเพื่อดึงเส้นทางคำร้องทั้งเส้น
ส่วนประกอบมากขึ้นมักหมายถึงการแจ้งเตือนมากขึ้น หากไม่จูน ทีมจะเกิด alert fatigue ตั้งเป้าให้เตือนที่ปฏิบัติได้จริงและอธิบาย:
ปัญหาความจุมักโผล่มาก่อนล้มเหลว ตรวจสอบสัญญาณอิ่มตัวเช่น CPU, memory, queue depth, การใช้ connection pool ถ้าสัญญาณอิ่มตัวปรากฏแค่บนบางโหนด ให้สงสัยการบาลานซ์ การชาร์ด หรือ configuration drift ไม่ใช่แค่ "ทราฟฟิกเยอะขึ้น"
เมื่อสเกลออก การ deploy ไม่ใช่แค่การแทนที่กล่องเดียว แต่มันคือการประสานการเปลี่ยนแปลงข้ามเครื่องหลายเครื่องในขณะยังให้บริการได้
การปรับใช้แนวนอนมักใช้ rolling updates (แทนที่โหนดทีละส่วน), canaries (ส่งส่วนน้อยของทราฟฟิกไปที่เวอร์ชันใหม่), หรือ blue/green (สลับทราฟฟิกระหว่างสอง environment เต็มรูป) เพื่อลด blast radius แต่ต้องการการจัดการการเลื่อนไหลของทราฟฟิก, health checks, draining การเชื่อมต่อ และนิยามของ "ดีพอที่จะไปต่อ"
ระหว่างการ deploy แบบค่อยเป็นค่อยไป เวอร์ชันเก่าและใหม่ทำงานร่วมกัน นั่นหมายความว่าระบบต้องรองรับพฤติกรรมผสม:
API ต้องรองรับ backward/forward compatibility schema DB ควรเปลี่ยนแบบ additive (เพิ่มคอลัมน์ nullable ก่อนทำให้ required) ฟอร์แมตข้อความควรเวอร์ชันเพื่อให้คอนซูเมอร์อ่าน event เก่าและใหม่ได้
ย้อนกลับโค้ดง่าย แต่ย้อนกลับข้อมูลไม่ง่าย หากมิเกรชันลบหรือเขียนฟิลด์เก่า โค้ดรุ่นเก่าอาจ crash หรือจัดการข้อมูลผิด พื้นที่ปลอดภัยคือการทำมิเกรตแบบ expand/contract: deploy โค้ดที่รองรับทั้งสองสกีมา, migrate ข้อมูล, แล้วลบโค้ดเก่าทีหลัง
กับหลายโหนด การจัดการการตั้งค่ากลายเป็นส่วนหนึ่งของการ deploy โหนดเดียวที่มีคอนฟิกเก่า ป้ายฟีเจอร์ผิด หรือข้อมูลรับรองหมดอายุ สามารถสร้างความล้มเหลวที่ยาก reproduce ได้
การสเกลแนวนอนอาจดูถูกกว่าเป็นหน่วย: อินสแตนซ์เล็ก ๆ หลายตัวราคาต่อชั่วโมงต่ำ แต่ค่าใช้จ่ายทั้งหมดไม่ใช่แค่ compute การเพิ่มโหนดหมายถึงแบนด์วิธเพิ่ม การมอนิเตอร์เพิ่ม การประสานงานเพิ่ม และเวลาที่ใช้รักษาความสอดคล้อง
การสเกลแนวตั้งทำให้ค่าใช้จ่ายรวมอยู่ที่เครื่องจำนวนน้อย — น้อย host ให้ patch, agent น้อย, logs น้อยให้ส่ง, เมตริกน้อยให้ scrape
กับสเกลออก ราคาต่อหน่วยอาจต่ำ แต่คุณมักจ่ายสำหรับ:
เพื่อรองรับพีก ระบบกระจายมักวิ่งแบบยังไม่เต็ม คุณต้องเผื่อ headroom ในหลายชั้น (เว็บ, worker, DB, cache) ซึ่งแปลว่าจ่ายค่าใช้จ่ายสำหรับความจุที่ไม่ได้ใช้ในหลายสิบหรือร้อยอินสแตนซ์
การสเกลออกเพิ่มภาระ on-call และต้องการเครื่องมือที่โตแล้ว: การจูนการแจ้งเตือน, runbooks, ฝึกซ้อมเหตุฉุกเฉิน, และการฝึกอบรม ทีมยังต้องใช้เวลาในการกำหนดขอบเขตความเป็นเจ้าของและประสานงานเหตุการณ์
ผลลัพธ์: “ถูกต่อหน่วย” อาจแพงกว่าเมื่อรวมเวลาและความเสี่ยงของคนเข้ามา
การตัดสินใจไม่ใช่แค่เรื่องราคา แต่เกี่ยวกับรูปแบบงานและความสามารถทีมในการรับความซับซ้อน
เริ่มจากงาน:
เส้นทางที่สมเหตุสมผล:
หลายทีมเก็บฐานข้อมูลแบบแนวตั้ง (หรือคลัสเตอร์เบา ๆ) ขณะที่สเกลชั้นแอปที่ stateless แบบแนวนอน เพื่อลดความยุ่งยากจากการชาร์ดแต่ยังเพิ่มความจุเว็บได้เร็ว
คุณใกล้จะพร้อมเมื่อมีมอนิเตอร์และการแจ้งเตือนที่ดี, failover ที่ทดสอบแล้ว, load tests, และการปรับใช้ที่ทำซ้ำได้พร้อม rollback ที่ปลอดภัย
ความเจ็บปวดจากการสเกลไม่ได้เป็นแค่สถาปัตยกรรม แต่เป็นลูปการปฏิบัติ: ทำซ้ำอย่างปลอดภัย ปรับใช้เชื่อถือได้ และย้อนกลับไวเมื่อแผนไม่ตรงกับความจริง
ถ้าคุณกำลังสร้างเว็บ แบ็กเอนด์ หรือระบบมือถือและอยากเคลื่อนไหวเร็วโดยไม่เสียการควบคุม Koder.ai ช่วยให้คุณทำต้นแบบและส่งงานได้เร็วขึ้นในขณะที่ตัดสินใจเรื่องการสเกลได้ดีขึ้น แพลตฟอร์มนี้เป็น vibe-coding ที่สร้างแอปผ่านแชท โดยมีสถาปัตยกรรมแบบ agent อยู่ใต้พื้น
ในทางปฏิบัติหมายถึงคุณสามารถ:
เพราะ Koder.ai รันบน AWS ทั่วโลก มันยังรองรับการปรับใช้ในหลาย region เพื่อจัดการเรื่อง latency และการโอนข้อมูล — ซึ่งมีประโยชน์เมื่อ multi-zone หรือ multi-region เป็นส่วนหนึ่งของเรื่องการสเกลของคุณ
การสเกลแนวตั้งหมายถึงการทำให้เครื่องเครื่องเดียวแข็งแรงขึ้น (เพิ่ม CPU/RAM/ดิสก์ที่เร็วกว่า) ส่วนการสเกลแนวนอนคือการเพิ่มเครื่องหลายเครื่องแล้วกระจายงานไปให้พวกมันทำ
การสเกลแนวตั้งมักรู้สึกง่ายกว่าเพราะแอปยังคงทำงานเหมือนเป็น “ระบบเดียว” ในขณะที่การสเกลแนวนอนต้องให้หลายระบบประสานงานและรักษาความสอดคล้องของสถานะร่วมกัน
ทันทีที่คุณมีหลายโหนด คุณต้องจัดการการประสานงานอย่างชัดเจน:
เครื่องเดียวช่วยหลีกเลี่ยงปัญหาระบบกระจายพวกนี้ได้โดยปริยาย จึงทำให้การสเกลแนวนอนซับซ้อนกว่า
มันคือเวลาที่ใช้และตรรกะในการทำให้หลายเครื่องทำงานร่วมกันเหมือนไม้หนึ่งชิ้น:
แม้แต่โหนดแต่ละตัวจะเรียบง่าย แต่พฤติกรรมของระบบเมื่อมีหลายโหนดจะยากต่อการคาดเดาเมื่อมีโหลดหรือความล้มเหลว
ชาร์ด (การแบ่งข้อมูล) แบ่งข้อมูลไปยังโหนดต่าง ๆ เพื่อไม่ให้เครื่องตัวเดียวเก็บ/ให้บริการทั้งหมด ปัญหาคือคุณต้อง:
นอกจากนี้งานปฏิบัติการอย่าง migration, backfill และการดูแผนที่ชาร์ดก็เพิ่มขึ้นตามมา
สถานะคือสิ่งที่แอปจำไว้ระหว่างคำขอหรือระหว่างกระบวนการ (เช่น session, cache ในหน่วยความจำ, ไฟล์ชั่วคราว, ความคืบหน้างาน)
เมื่อสเกลออก คำขออาจไปตกที่เซิร์ฟเวอร์ต่างกัน ดังนั้นคุณต้องตัดสินใจจะเก็บสถานะไว้ที่ไหน เช่น:
ระบบ background ก็ต้องออกแบบให้ไม่ประมวลผลซ้ำ เช่น ใช้คิว, สัญญาเช่า/ล็อก, หรือทำให้งาน idempotent
ถ้า worker หลายตัวดึงงานเดียวกัน อาจเกิดการประมวลผลซ้ำ เช่น เก็บเงินสองครั้งหรือส่งอีเมลซ้ำได้
แนวทางป้องกันที่ใช้บ่อย:
ความสอดคล้องแบบเข้มงวดหมายถึงเมื่อเขียนเสร็จแล้ว ผู้อ่านทุกคนจะเห็นค่าล่าสุดทันที ส่วน eventual consistency หมายถึงการอัพเดตจะกระจายไปเรื่อย ๆ จึงอาจมีผู้อ่านเห็นข้อมูลเก่าในช่วงสั้น ๆ
ใช้ความสอดคล้องแบบเข้มงวดกับข้อมูลที่ต้องถูกต้องจริง ๆ (ชำระเงิน ยอดเงิน สต็อกที่นั่ง) ส่วนข้อมูลที่ไม่ต้องทันทีเช่น analytics หรือคำแนะนำ อาจยอมรับ eventual consistency
การสื่อสารระหว่างโหนดกลายเป็นการเรียกผ่านเครือข่าย ซึ่งเพิ่มความหน่วง ความแปรปรวน และความผิดพลาด
สิ่งพื้นฐานที่มักสำคัญ:
partial failure คือสถานะที่บางส่วนของระบบล้มเหลวหรือช้าขณะที่ส่วนอื่นปกติ ระบบยังอาจขึ้นแต่ผู้ใช้เห็นข้อผิดพลาดหรือหน้านาน ๆ ได้
แนวทางออกแบบรวมถึง replication, quorums, การกระจายข้ามโซน, circuit breakers และ graceful degradation เพื่อไม่ให้ความล้มเหลวขยายวงกว้าง
เมื่อแอปรันบนหลายเซิร์ฟเวอร์ เบาะแสกระจายอยู่หลายที่: logs, metrics, traces อยู่บนโหนดต่างกัน
ขั้นตอนปฏิบัติ: