โซลูชันฐานข้อมูลที่สร้างสรรค์ได้จุดประกายการพูดคุยในชุมชนนักพัฒนา หลังจากที่วิศวกรคนหนึ่งแชร์วิธีที่พวกเขาป้องกันความล้มเหลวของระบบที่อาจเกิดขึ้น โดยการใช้ประโยชน์จากฟีเจอร์ที่มักถูกมองข้ามของ signed integers เรื่องราวนี้เน้นย้ำว่าบางครั้งแนวทางที่ไม่ธรรมดาสามารถซื้อเวลาที่สำคัญสำหรับการแก้ไขที่เหมาะสมได้
สถานการณ์นี้เกี่ยวข้องกับแพลตฟอร์มปฏิทินที่ใกล้จะถึงจุดวิกฤต primary key ของตาราง occurrence กำลังใกล้ถึง 2,147,483,647 ซึ่งเป็นค่าสูงสุดสำหรับ signed 32-bit integer ด้วยข้อมูลปฏิทิน 12 ปีและผู้ใช้หลายล้านคนที่พึ่งพาระบบนี้ การหมด primary key space จะเป็นหายนะ
ขีดจำกัดของ Signed Integer แบบ 32-bit:
- ค่าบวกสูงสุด: 2,147,483,647
- ค่าลบต่ำสุด: -2,147,483,648
- จำนวนค่าที่ไม่ซ้ำกันทั้งหมดที่ใช้ได้: ประมาณ 4.3 พันล้าน
- เวลาที่ได้รับจากการใช้พื้นที่ค่าลบ: สูงสุด 3 ปี (แผนการทำความสะอาด: 6-8 เดือน)
วิธีแก้ปัญหาที่ชาญฉลาดแต่ก่อให้เกิดความเห็นแตกต่าง
ในขณะที่ทีมได้เตรียม migration ที่เหมาะสมไปยัง 64-bit integers แล้ว พวกเขาค้นพบอุปสรรคใหญ่เพียงหนึ่งสัปดาห์ก่อนการ deployment integer keys ถูกเปิดเผยใน public APIs และการเปลี่ยนแปลงอาจทำให้ customer integrations เสียหาย แผนก IT ของมหาวิทยาลัยซึ่งมักรับผิดชอบ integrations เหล่านี้ มักมี backlogs ที่วัดเป็นเดือนมากกว่าสัปดาห์
โซลูชันนี้เรียบง่ายและสง่างาม: รีเซ็ต sequence ให้เริ่มต้นที่ -2,147,483,648 และทำ auto-increment ต่อไปผ่าน negative number space แนวทางนี้เพิ่ม key space ที่ใช้ได้เป็นสองเท่าโดยไม่ต้องเปลี่ยน data type หรือทำลาย existing integrations
ปฏิกิริยาของชุมชนต่อแนวทางนี้มีความหลากหลายแต่ส่วนใหญ่เป็นบวก นักพัฒนาบางคนไม่ถือว่ามันเป็น hack โดยสังเกตว่าตัวเลขติดลบมีความถูกต้องเท่ากับตัวเลขบวกสำหรับ unique identifiers อย่างไรก็ตาม คนอื่นๆ ชี้ให้เห็นปัญหาที่อาจเกิดขึ้นกับโค้ดที่สมมติว่า primary keys เพิ่มขึ้นเสมอ ซึ่งอาจทำให้เกิดปัญหาเมื่อ sequence เปลี่ยนจากบวกเป็นลบ
ไทม์ไลน์กลยุทธ์การย้ายระบบ:
- การระบุปัญหา: 1.5 เดือนก่อนการปรับใช้งาน
- การค้นพบการพึ่งพา API: 1 สัปดาห์ก่อนการปรับใช้งาน
- การใช้งาน negative key: ทันที
- การวางแผนย้ายระบบอย่างเหมาะสม: 6-8 เดือน
- เวลาสูงสุดที่มี: 3 ปี
Technical Debt ที่ทำอย่างถูกต้อง
เรื่องราวนี้สะท้อนใจนักพัฒนาเพราะแสดงให้เห็นการจัดการ technical debt อย่างมีความรับผิดชอบ แทนที่จะรีบเร่งการเปลี่ยนแปลงที่อาจทำลายระบบ ทีมเลือกโซลูชันชั่วคราวที่ซื้อเวลาหายใจ 3 ปี ในขณะที่มุ่งมั่นที่จะดำเนินการแก้ไขที่เหมาะสมภายใน 6 ถึง 8 เดือน
โซลูชันระยะยาวไม่เพียงแค่อัปเกรดเป็น 64-bit integers เท่านั้น แต่ยังรวมถึงการออกแบบ API ใหม่เพื่อใช้ opaque handles แทนการเปิดเผย raw database keys แนวทางนี้ป้องกัน dictionary attacks และให้ความยืดหยุ่นมากขึ้นแก่นักพัฒนาในการ implement backend โดยไม่ส่งผลกระทบต่อผู้ใช้ API
Key ต้องเป็นตัวเลขที่ไม่ซ้ำกัน -1 และ 1 เป็นตัวเลขที่แตกต่างกันสองตัว
บทเรียนสำหรับการออกแบบฐานข้อมูล
เหตุการณ์นี้เน้นย้ำข้อพิจารณาสำคัญหลายประการสำหรับสถาปนิกฐานข้อมูล การเปิดเผย internal database identifiers ผ่าน public APIs สร้างการเชื่อมโยงระหว่างรายละเอียดการ implement และ external contracts เมื่อ APIs เหล่านั้นถูกใช้โดยองค์กรที่มีกระบวนการเปลี่ยนแปลงช้า การเชื่อมโยงนี้จะกลายเป็นปัญหามากยิ่งขึ้น
เรื่องราวนี้ยังแสดงให้เห็นความสำคัญของการติดตามขีดจำกัดของระบบล่วงหน้า แม้ว่าทีมจะระบุขีดจำกัดที่ใกล้เข้ามาและเตรียมโซลูชันไว้แล้ว แต่การพึ่งพา API ถูกค้นพบเกือบสายเกินไป การระบุก่อนหน้านี้อาจให้เวลามากขึ้นสำหรับการสื่อสารกับลูกค้าและการวางแผน migration
โซลูชันนี้ทำงานได้อย่างไร้ที่ติ ช่วยให้การเปลี่ยนผ่านของลูกค้าเป็นไปอย่างราบรื่นและการทำความสะอาดที่เหมาะสมภายในกรอบเวลาที่วางแพนไว้ มันเป็นการเตือนใจว่าบางครั้งโซลูชันทางวิศวกรรมที่ดีที่สุดไม่ใช่โซลูชันที่สง่างามที่สุด แต่เป็นโซลูชันที่แก้ปัญหาเฉพาะหน้าในขณะที่สร้างพื้นที่สำหรับการแก้ไขระยะยาวที่ถูกต้อง