🧱 “Scalable แต่เปลือง — เมื่อสตาร์ทอัพยุคใหม่สร้างระบบแบบ Google แต่มีลูกค้าแค่ 2 คน” Stavros เปิดบทความด้วยการเสียดสีว่า “ทุกคนเป็นวิศวกรจาก FAANG” เพราะไม่ว่าจะเป็นสตาร์ทอัพเล็กหรือใหญ่ ทุกคนดูเหมือนจะสร้างระบบแบบเดียวกัน: ใช้ AWS/GCP, มี microservices เป็นสิบ, ใช้ orchestrator ซับซ้อน, autoscaling พร้อมระบบ distributed datastore ที่อ่านข้อมูลช้าลงตามเวลาที่เขียนล่าสุด เขาตั้งคำถามว่า “ทำไมทุกคนถึงรีบแก้ปัญหา scalability ก่อนจะมีลูกค้าจริง?” ทั้งที่ปัญหาแรกของสตาร์ทอัพควรจะเป็น “จะอยู่รอดได้อีก 2 เดือนหรือไม่” ไม่ใช่ “จะรองรับผู้ใช้ล้านคนได้อย่างไร” Stavros เสนอว่าแทนที่จะสร้าง distributed monolith ที่ซับซ้อนตั้งแต่วันแรก เราควรเริ่มจาก monolith ที่มีโครงสร้างดี ใช้ module ที่แยกกันชัดเจน มี interface แบบ statically typed และใช้ type checker เพื่อควบคุมการเปลี่ยนแปลง API ได้อย่างปลอดภัย เขายอมรับว่าการใช้ monolith มีข้อเสีย เช่น ไม่สามารถ scale เฉพาะ module ได้ง่าย แต่ข้อดีคือความเร็ว ความเรียบง่าย และความสามารถในการเปลี่ยนแปลงแบบ atomic โดยไม่ต้อง version API หรือ debug payload ที่ซับซ้อน ✅ สตาร์ทอัพยุคใหม่มักสร้างระบบแบบ FAANG โดยไม่จำเป็น ➡️ ใช้ microservices, distributed datastore, autoscaling ตั้งแต่วันแรก ✅ ปัญหาแรกของสตาร์ทอัพควรเป็น “การอยู่รอด” ไม่ใช่ “scalability” ➡️ แต่ scalability ง่ายกว่าและดูเท่กว่าในเรซูเม่ ✅ ระบบที่ซับซ้อนมีต้นทุนสูง ทั้งด้านเงินและเวลา ➡️ โดยเฉพาะเมื่อยังไม่มีผู้ใช้จริง ✅ Stavros เสนอให้ใช้ monolith ที่มี module แยกกันชัดเจน ➡️ ใช้ interface แบบ statically typed และ type checker ✅ ข้อดีของ monolith คือความเร็วและความสามารถในการเปลี่ยน API ได้ทันที ➡️ ไม่ต้อง version endpoint หรือ debug dict ซับซ้อน ✅ การใช้ monorepo ไม่จำเป็น แต่ช่วยให้ deploy แบบ atomic ได้ง่าย ➡️ เป็น trade-off ที่แต่ละทีมต้องตัดสินใจเอง ‼️ การสร้างระบบซับซ้อนตั้งแต่ต้นอาจทำให้สตาร์ทอัพล้มก่อนจะมีผู้ใช้จริง ⛔ เพราะใช้ทรัพยากรไปกับสิ่งที่ยังไม่จำเป็น ‼️ การออกแบบเพื่อ “เรซูเม่” มากกว่าความต้องการจริงของธุรกิจ ⛔ ทำให้ระบบเต็มไปด้วยเทคโนโลยีที่ไม่ก่อให้เกิดรายได้ ‼️ การใช้ distributed architecture โดยไม่จำเป็น ⛔ ทำให้เกิดความซับซ้อนที่ไม่คุ้มค่าในระยะเริ่มต้น ‼️ การหลีกเลี่ยง monolith เพราะกลัว “ball of yarn” ⛔ อาจทำให้พลาดโอกาสในการสร้างระบบที่เร็วและง่ายต่อการดูแล https://www.stavros.io/posts/why-is-everything-so-scalable/