แนวทางในการปรับปรุงให้ระบบงานเร็วขึ้น

หนึ่งในปัญหาของระบบงานคือ ล่ม
แต่การล่มอีกหนึ่งรูปแบบคือ ช้า
ช้า === ล่ม
ซึ่งล้วนส่งผลต่อความน่าเชื่อถือของระบบ
ทั้งจากผู้ใช้งาน และ business ด้วย
ดังนั้นสิ่งทีมพัฒนาจะต้องเข้าใจคือ แนวทางในการปรับปรุงระบบให้ทำงานเร็วขึ้น
มาดูว่ามีอะไรบ้าง ?

ฝั่งคนใช้งาน คงไม่แก้ไขด้วยการเพิ่ม timeout หรอกนะ ?
ไม่มีใครเขาทำกัน !!

จากการเข้าไป review architecture และ source code
รวมถึงการปรับปรุงไปนิดหน่อย
จึงทำการสรุปไว้ดังนี้

• ทำ caching และ pre-caching ในทุก ๆ level ทั้ง frontend, backend, data (denormalization), network, file, CDN
• ทำ caching แล้วอย่าลืมเรื่องของการ purge data ด้วย หรือเรื่อง expired time
• ออกแบบ business process flow ให้ชัดเจน ไม่ยาวจนเกินไป หรือ ไม่โดยน flow ของภายใน ออกไปให้ลูกค้า หรือ ผู้ใช้งานมารอ ให้รอเท่าที่จำเป็นเท่านั้น
• จากเรื่อง business process flow นั้น อาจจะต้องออกแบบ UX/UI flow ใหม่ด้วย เพื่อปรับเปลี่ยนพฤติกรรมการทำงานของระบบ
• ถ้าแยกเป็น frontend/backend/micoroservice อย่าให้ผูกมันกันมากนัก อาจจะกันด้วย api gateway, load balancing, service discovery ไว้ด้วย ทำให้เอื้อต่อการเปลี่ยนแปลง หรือ จัดการง่ายเมื่อมันพัง
• การติดต่อสื่อสารระหว่างส่วนงานต่าง ๆ อาจจะต้องปรับเปลี่ยนไปใช้งาน asynchonous communication หรือ processing อีกด้วย แต่อย่าลืมว่า ช้า === ล่มนะ ถึงแม้ทาง IT จะบอกว่าไม่ล่ม แต่ส่ง responseไปยังลูกค้าช้า !! ดังนั้นต้องมองให้ครบแบบ end-to-end
• การทำงานกับ database ถ้ามันช้าก็จัดการหลาย ๆ ส่วน ทั้ง design for read และ design for write, normalization vs normalization, indexing ให้เหมาะสม, data sharding/partition, เลือกใช้ databasae model ให้เหมาะกับงานด้วย อย่าลืมดู slow log กันด้วย
• เมื่อพูดถึงเรื่อง data ก็อย่าลืมบีบอัดข้อมูลที่ส่งไปมาผ่านระบบ network กันด้วย รวมทั้ง connection ด้วยว่าต้องใช้ keep-alive นานเท่าไร อย่างไร ในแต่ละ usecase
• วาด flow การทำงานของระบบด้วยในแต่ละเรื่องด้วย เพื่อให้เข้าใจว่าทำงานอย่างไร
• เรื่องของ observability ของระบบขาดไม่ได้เลย เช่น metric, trace และ log เป็นต้น อีกตัวที่ชอบใช้คือ exception tracking
• เรื่องของการ write log ของระบบ เจอว่ายังทำงานแบบ synchพonous อยู่เลย ตรงนี้แก้ได้แก้เลย

ปล. ระบบทำงานเร็วอย่างเดียวยังไม่เพียงพอ

ต้องทำงานได้อย่างถูกต้องด้วย ดังนั้น
เรื่องของ การทดสอบ จึงสำคัญ
เรื่องของ observability จึงสำคัญ
และรับ feedback จากผู้ใช้งาน ยิ่งสำคัญมาก ๆ
ดังนั้น feedback loop ยิ่งเร็วยิ่งดี