จากบทความเรื่องการ scale ระบบของ Levels.fyi
พบว่าน่าสนใจมาก ๆ สำหรับการเริ่มต้นทำ product
เริ่มแบบเรียบง่ายเพื่อ validate ว่า product จะไปได้ไหม
จากนั้นค่อย ๆ optimize หรือปรับเปลี่ยนไปตามความต้องการ
หรือตาม business และคนใช้งานที่สูงขึ้น
ดังนั้นจึงสรุปสิ่งที่น่าสนใจไว้นิดหน่อย
สิ่งที่ได้ใจมาก ๆ คือ เริ่มด้วยการเน้นไปที่การสร้าง product
ว่าสิ่งที่คิด มันจะ work หรือมีผู้ใช้งานหรือไม่
เพราะว่า แนวคิดที่คิดหรือทำมานั้น อาจจะเป็นเพียงสิ่งที่เราต้องการเองเท่านั้น !!
ดังนั้นการลงทุนสร้างระบบจึงเรียบง่ายมาก ๆ
คือเริ่มจาก Google Forms และ Google Sheets เท่านั้น (No Code ชัด ๆ)
ไม่ต้องมาเสียเงินพัฒนา และดูแลหลังบ้านอะไร
- Frontend = Google Forms
- Database = Google Sheets
ตรงนี้เรียกว่า version 0
ต่อมาเพิ่มส่วนของ User Interface เข้ามา เพราะว่าข้อมูลเริ่มซับซ้อนขึ้น
เช่นข้อมูลเงินเดือน
จากนั้นก็เพิ่ม API gateway และ AWS Lambda (serverless) เข้ามา
เพื่อทำการตรวจสอบข้อมูล และ บันทึกข้อมูลไปยัง Google Sheets ต่อไป
ส่วนนี้เรียกว่า version 1
แต่การดึงข้อมูลจาก Google Sheets จะยากและประสิทธิภาพไม่ดี
จึงทำการสร้างข้อมูลเป็นไฟล์ JSON ขึ้นมา
จากนั้นทำการเก็บไฟล์ไว้ใน Amazon S3
เป็นการจัดเก็บแบบ upsert คือ
ถ้าไม่มีก็ insert หรือสร้างใหม่ ถ้ามีก็ทำการ update นั่นเอง
และการใช้งานจาก web browser ก็เข้าถึงข้อมูลผ่าน CDN
ด้วยข้อมูลในไฟล์ JSON จะมีขนาดใหญ่
ดังนั้นก็ทำ caching ไว้ใน web browser อีกด้วย
โครงสร้างนี้ทำงานได้ดีมาเรื่อย ๆ ( 24 เดือนหรือ 2 ปี)
แต่เมื่อมีผู้ใช้งานสูงขึ้น ก็เจอปัญหาเหล่านี้
- ขนาดของไฟล์ JSON มีขนาดใหญ่ขึ้น จาก KB มาเป็น MB ดังนั้นเมื่อผู้ใช้งานใหม่ เข้ามาพร้อม ๆ กัน ทำให้ loading time เยอะมาก ๆ
- AWS Lambda ทำการช้า จน timeout กันไปเลย
- ขาดวิธีการนำ data มาวิเคราะห์ เพื่อใช้ในการตัดสินใจ ซึ่งเป็นปัญหาที่ใหญขึ้น
- Google Sheets API มาถึง rate limit ของมัน สำหรับการเขียนข้อมูล
- ง่ายดูการ scrape ข้อมูลมาก ๆ เพราะว่า return เป็น JSON กลับมายัง web browser
ดังนั้นจึงได้เวลาของการปรับเปลี่ยนครั้งใหญ่ของ Architecute ระบบ
โดยในฝั่ง backend ได้นำ database มาใช้เก็บข้อมูลแทน Google Sheets
เป็นแนวทางที่ขับเคลื่อนด้วยปัญหาที่พบ
รวมทั้งทำการแบ่งข้อมูลที่อยู่ในไฟล์ JSON เป็นไฟล์เล็ก ๆ
โดยทำการสร้าง API ใหม่ขึ้นมาเพื่อให้ทาง frontend เรียกใช้งาน
ทำแบบค่อยเป็นค่อยไป จนย้ายทุกส่วนมายัง API ใหม่
ฝั่งของ API server พัฒนาด้วย Node.js ทำงานบนเครื่องเดียว
สามารถรองรับผู้ใช้งาน 60K request ต่อชั่วโมง
จะเห็นได้ว่าการออกแบบระบบนั้น เป็นไปแบบธรรมชาติ
ตามเป้าหมายของระบบ นั่นคือ
ต้องการได้รับ feedback จากผู้ใช้งานหรือลูกค้าอย่างรวดเร็ว
แถมระบบต้องดีพอสำหรับผู้ใช้งานด้วยนะ
เพื่อช่วยทำให้มั่นใจว่า product ที่เราคิดนั้นมันใช่หรือไม่
จากนั้นก็ค่อย ๆ ปรับปรุง ปรับเปลี่ยน ให้เหมาะสมต่อไป
ช่วยลดความเสี่ยงในเรื่องต่าง ๆ ลงไปได้เยอะ
มันคือ Evolution Architecture นั่นเอง
