คำถามสัมภาษณ์ Microservices

คุณอ่านชื่อแพทเทิร์นมาหมดแล้ว ท่องได้ว่า circuit breaker ทำงานอย่างไร แต่ก็ยังบอกไม่ได้ว่าคณะกรรมการสัมภาษณ์กำลังฟังหาอะไรอยู่ ส่วนนี้จะบอกสี่ด้านที่ผู้สัมภาษณ์ให้คะแนน เรียงตามลำดับที่มักจะถามถึง แต่ละด้านคือคำถามเชิงวิจารณญาณที่แฝงตัวมาในรูปคำถามเชิงคำศัพท์

• Decomposition. คุณตัดแบ่งตรงไหน และทำไมต้องตรงนั้น ผู้สัมภาษณ์ต้องการเห็นขอบเขตที่ลากตามความสามารถทางธุรกิจหรือความเป็นเจ้าของข้อมูล ไม่ใช่ตามเลเยอร์ทางเทคนิค
• Communication. เรียกแบบ synchronous request/response หรือแบบ asynchronous events และแต่ละแบบพังตรงไหน คำตอบที่ต้องการคือการชั่งน้ำหนักข้อดีข้อเสีย ไม่ใช่ความชอบส่วนตัว
• Data. หนึ่งฐานข้อมูลต่อหนึ่งบริการ หมายความว่าไม่มีการ join ข้ามบริการและไม่มี distributed transaction แล้วคุณจะรักษาความถูกต้องของระบบได้อย่างไร
• Operations. การดีพลอย การกำหนดเวอร์ชัน การตามรอย และจะทำอย่างไรตอนตีสามเมื่อบริการหนึ่งช้าแทนที่จะล่ม

สังเกตว่าไม่มีข้อไหนเกี่ยวกับเฟรมเวิร์กเลย ผู้สมัครที่อธิบายได้ว่าทำไมถึงแยก checkout ออกจาก inventory จะได้คะแนนเหนือกว่าคนที่ท่องรายชื่อ annotation ทุกครั้งไป

นี่คือคำถามที่มักเปิดฉากรอบสัมภาษณ์ microservices ส่วนใหญ่ พร้อมสิ่งที่ผู้สัมภาษณ์กำลังตรวจสอบอยู่เบื้องหลังแต่ละข้อ

• จะแยกโมโนลิธนี้ออกเป็นเซอร์วิสอย่างไร? ตรวจว่าคุณตัดตามความสามารถทางธุรกิจและความเป็นเจ้าของข้อมูล หรือตัดตามเลเยอร์ controller, service และ repository คำตอบแบบหลังจะได้ distributed monolith
• สองเซอร์วิสคุยกันอย่างไร? ตรวจว่าคุณบอกต้นทุนของแต่ละทางเลือกได้หรือไม่ การเรียกแบบ synchronous ให้โมเดลความคิดที่เข้าใจง่ายแต่ผูก availability เข้าด้วยกัน ส่วน asynchronous events แยก availability ออกจากกันแต่ต้องอธิบาย eventual consistency ให้เจ้าของผลิตภัณฑ์ฟัง
• Distributed monolith คืออะไร และหลีกเลี่ยงได้อย่างไร? ตรวจว่าคุณรู้หรือไม่ว่าเซอร์วิสที่ต้องดีพลอยพร้อมกันไม่ได้แยกจากกันจริง ๆ
• เซอร์วิสหนึ่งควรมีขนาดใหญ่แค่ไหน? ตรวจว่าคุณไม่ยึดติดกับตัวเลขตายตัว ขนาดขึ้นอยู่กับขอบเขตและทีมที่เป็นเจ้าของ
• ต้องมี API gateway ไหม และมันทำหน้าที่อะไร? ตรวจว่าคุณแยก routing, authentication และ rate limiting ออกจาก business logic ได้หรือไม่
• เซอร์วิสค้นหากันเจอได้อย่างไร? ตรวจความคุ้นเคยพื้นฐานกับ service discovery และเหตุผลที่ hardcoded host ล้มเหลวในสภาพแวดล้อมที่ขยายสเกล

พูดการชั่งน้ำหนักข้อดีข้อเสียออกมาดัง ๆ ในทุกคำตอบ คณะกรรมการให้คะแนนสิ่งที่คุณเปรียบเทียบอยู่ในหัวเงียบ ๆ ไม่ได้

ตรงนี้คือจุดที่ตัดสินว่าสัมภาษณ์จะผ่านหรือไม่ผ่าน เพราะคำถามกลุ่มนี้ไม่มีคำตอบสำเร็จรูป แต่ผู้สมัครมักหยิบคำตอบที่ท่องมาออกมาใช้

• รักษาความสอดคล้องของข้อมูลข้ามเซอร์วิสได้อย่างไร? ให้บอกข้อจำกัดก่อนเลย นั่นคือไม่มี transaction ข้ามเซอร์วิส จากนั้นอธิบาย saga ไม่ว่าจะเป็นแบบ choreographed ผ่าน event หรือแบบ orchestrated โดย coordinator แล้วพูดตรง ๆ ว่าระบบเป็น eventually consistent และผู้ใช้เห็นอะไรในช่วงที่ข้อมูลยังไม่ตรงกัน
• ถ้าเซอร์วิสปลายทางช้าจะเกิดอะไรขึ้น? ตั้ง timeout, retry แบบมี backoff และใส่ circuit breaker เพื่อไม่ให้ dependency ที่ช้าดึง thread pool จนหมด ช้ากว่าล่มเสียอีก และการพูดแบบนี้บ่งบอกประสบการณ์จริงในโปรดักชัน
• ทำอย่างไรให้ retry ปลอดภัย? Idempotency คือคำตอบ ใส่ idempotency key ไว้บนเส้นทางเขียนข้อมูล เพื่อให้การชำระเงินที่ถูก retry เกิดขึ้นแค่ครั้งเดียว
• จัดการความล้มเหลวบางส่วนในโฟลว์หลายขั้นตอนอย่างไร? ใช้ compensating action ไม่ใช่ rollback อธิบายให้ได้ว่าการคืนเงินหรือปลดการจองหน้าตาเป็นอย่างไร
• ดีบักคำขอที่ผ่านหกเซอร์วิสได้อย่างไร? ใช้ distributed tracing ที่มี correlation ID ส่งผ่านทุก hop พร้อม structured log และ metric

วิศวกร backend คนหนึ่งที่สัมภาษณ์ตำแหน่ง platform ระดับ L5 ที่ผู้ให้บริการ public cloud รายหนึ่ง เจอคำถามเรื่อง saga และตอบผ่านไปรอบเดียวด้วยศัพท์แพทเทิร์นล้วน ๆ โดยไม่พูดถึงเลยว่าลูกค้าจะเห็นอะไร คำถามตามที่ว่าหน้าออเดอร์จะแสดงผลอย่างไรในช่วงที่ข้อมูลยังไม่สอดคล้องกัน ต่างหากคือคำถามที่ตัดสินผลรอบสัมภาษณ์จริง ๆ เตรียมคำตอบที่สองไว้ด้วย ไม่ใช่แค่คำตอบแรก

คลังคำถามเพิ่มเติมตามตำแหน่งและหัวข้ออื่น ๆ รวบรวมไว้ใน คำถามสัมภาษณ์แยกตามตำแหน่ง

การอ่านลิสต์นี้ทำให้เกิดความรู้สึกคุ้น ๆ แต่ความคุ้นนั้นหายไปทันทีที่มีคนแปลกหน้าถามคำถามแล้วนั่งรอฟัง ช่องว่างระหว่างการรู้จักแพทเทิร์นกับการอธิบายมันภายใต้แรงกดดันเล็กน้อยคือความยากทั้งหมดของรอบ system design และมันจะปิดได้ด้วยการพูดออกมาเท่านั้น

เลือกโฟลว์หนึ่งที่คุณรู้จักดี เช่นการสั่งซื้อหรือการสมัครสมาชิก แล้วเล่าการแบ่งส่วนทั้งหมดออกมาดัง ๆ ทั้งขอบเขต ทางเลือกการสื่อสาร เรื่องความสอดคล้องของข้อมูล และเรื่องความล้มเหลว ทำซ้ำจนกว่าจะเลิกพูดสะดุดแล้วเริ่มประโยคใหม่ คุณสามารถลองพรอมพ์เหล่านี้กับ AI ผู้สัมภาษณ์ที่ถามคำถามต่อเนื่องและให้คุณตอบด้วยเสียงได้ในโหมด จำลองสัมภาษณ์ ซึ่งใกล้เคียงของจริงมากกว่าการอ่านโน้ตซ้ำ ๆ

Aaron Cao ผู้ก่อตั้ง SubcueAI สร้างโหมดฝึกซ้อมนี้ขึ้นมาเพื่อปิดช่องว่างนั้นโดยเฉพาะ ไม่ใช่เพื่อการนำเสนอเนื้อหา รายการคำถามหาได้ฟรีทั่วไปอยู่แล้ว สิ่งที่ผู้สมัครขาดคือการได้ฝึกพูดคำตอบซ้ำ ๆ ขณะที่มีคนรอฟังอยู่ ระหว่างสัมภาษณ์จริง แอปเดสก์ท็อปและ Side Panel ของส่วนขยายเบราว์เซอร์สามารถแสดงพรอมพ์ที่จัดโครงสร้างไว้ขณะที่ผู้สัมภาษณ์กำลังพูด แม้คำอธิบายที่ซ้อมมาแล้วจะดีกว่าคำอธิบายที่อ่านเป็นครั้งแรกเสมอ สิ่งที่ผู้ช่วยนี้ทำได้และทำไม่ได้อธิบายไว้ใน ภาพรวมผลิตภัณฑ์