จากบทความเรื่องการ scale ระบบของ Levels.fyi พบว่าน่าสนใจมาก ๆ สำหรับการเริ่มต้นทำ productเริ่มแบบเรียบง่ายเพื่อ validate ว่า product จะไปได้ไหมจากนั้นค่อย ๆ optimize หรือปรับเปลี่ยนไปตามความต้องการหรือตาม business และคนใช้งานที่สูงขึ้นดังนั้นจึงสรุปสิ่งที่น่าสนใจไว้นิดหน่อย
จาก Podcast เรื่อง API Evolution without Versioning with Brandon Byarsแค่เห็นหัวข้อก็น่าสนใจแล้วเลยลองฟังไปขณะที่นั่ง (ยืน) รถไฟฟ้าไปทำงานหน่อยที่ดีอีกอย่างคือ มีการ transcript ของ Podcast ให้อ่านไปด้วยจึงทำให้ได้ทั้งฟัง และ อ่าน ไปทั้งคู่มาดูกันว่า มีอะไรที่น่าสนใจบ้าง
ปัญหาที่มักพบเจอบ่อยมาก ๆ ของระบบงานคือการแย่งใช้งาน resource ต่าง ๆ ที่มีจำกัด พร้อมกันผลที่ตามมาคือ ระบบงานทำงานไม่ถูกต้องเช่น เกิดการทำงานซ้ำ เป็นต้นหรือเราจะเรียกว่า race condition
หลังจากที่พูดคุยเรื่องการนำ Redis มาใช้งานทั้งการจัดเก็บข้อมูลชั่วคราว (caching data)ทั้งการใช้งาน pub/sub สำหรับ messaging systemซึ่งมีการสรุปเรื่อง architecture ของ Redis ที่เหมาะสมต่องานมีรูปแบบต่าง ๆ ดังนี้
วันนี้นั่งอ่านบทความเรื่อง Postgres: a better message queue than Kafka?ทำการอธิบายการสร้างระบบ loggingซึ่งทำงานอยู่บน PostgreSQLว่ามีข้อดีและข้อเสียอย่างไร รวมทั้งการปรับปรุงในอนาคตทำไมถึงใช้งาน PostgreSQL แทนที่จะเป็น Apache Kafka สำหรับ message queue
ทาง Cockroach Labs นั้น ได้แจกฟรีหนังสือ Foundations of Scalable Systemsตั้งแต่บทที่ 1 – 3 ประกอบไปด้วย Introduction to scalable systems Distributed system architecture Distributed system essentials
ระบบที่ TD หรือ ถูกดี ดูแลคือ การสร้างระบบ POS (Point of Sales)สำหรับร้านค้าโชว์ห่วยเล็ก ๆ ซึ่งมีมากกว่า 100,000 ร้านค้าดังนั้นถ้าคิดง่าย ๆ ถ้าแต่ละร้านมี transaction วันละ 100 ก็ตีง่าย ๆ คือ ต้องรองรับ 1,000,000 transaction ต่อวันนี่คือ ความท้าทายที่ทีมต้องจัดการให้ได้ เป็นที่มาของ session นี้คือ The 3 years journey behind POS and ERP that handle s 1M+ transactions per day
มีเรื่องของ Data architecture ที่ต้องทำเลยสรุปเรื่องของ Data architecture ไว้หน่อยว่ามีความเป็นมาอย่างไรบ้างเราอยู่ตรงไหน และจะไปทางไหนต่อ
พอดีมีการพูดคุยเรื่องของ Playwright กันนิดหน่อยสิ่งที่น่าสนใจคือ โครงสร้างหรือ architecture ของ Playwright ว่าเป็นอย่างไรรวมทั้งการแก้ไขปัญหาที่มักเกิดขึ้นจาก end-to-end testingนั่นก็คือ Flaky test หรือการทดสอบที่พังง่าย และ หาปัญหาได้ยากมากๆทำให้ชุดการทดสอบไม่น่าเชื่อถือ
จากบทความเรื่อง Reducing Database Loadingอธิบายถึงแนวทางการลดการใช้งาน database ได้อย่างไรบ้างรวมทั้งแนวทางให้ database มีความยืดหยุ่นต่อการใช้งานมากยิ่งขึ้นมาดูว่ามีวิธีการอะไรที่น่าสนใจบ้างเป็นเรื่องพื้นฐานที่สำคัญมาก ๆ มาเริ่มกันเลย