على مدار العام الماضي، ومع النمو الأسّي لحركة Git، بدأت شبه جميع مستودعات Git على GitHub تعيش في مكانين في الوقت نفسه: مراكز بيانات GitHub الخاصة وAzure. لا تزال أكثر المستودعات نشاطًا مقيدة بعامل واحد: زمن ذهاب وإياب قدره 25 ميلي ثانية بين المناطق.
في منشور سابق، عرضت GitHub مبدأين وراء بنية التخزين من الجيل التالي: تقليل التنسيق وفصل التخزين عن الحوسبة. يتناول هذا المنشور الجسر بين التصميم القديم والجديد. فقد أدى تغيير طريقة تسلسل الكتابات في آلية النصاب إلى نقل أكثر المستودعات نشاطًا إلى Azure، وفتح هذه الخطوة نفسها الباب أمام نسخ متماثلة لا تحتفظ بحالة دائمة خاصة بها.
كان توقيت النقل مدفوعًا بالتحول نحو الأنظمة الوكيلة: حركة مرور تنمو بسرعة، وسقف صارم على قدرة الطاقة في مراكز بيانات GitHub والمنطقة المحيطة بها، وقيود مادية في سلسلة الإمداد. أتاحت القدرة المتبقية وقتًا كافيًا للنقل بأمان، لكنه لم يكن كافيًا للنقل ببطء. ولأن عمليات Git خدمة من الفئة 0 يعتمد عليها تقريبًا كل شيء في GitHub، كان لا بد من نقل البيانات أولًا، مع تطور البنية بعد وصولها. وصلت أول نسخة من أحد المستودعات إلى منطقة Central US في Azure في أغسطس 2025. واليوم، يملك معظم المستودعات نسختين من أصل خمس نسخ متماثلة في Azure، وتخدم Azure نحو نصف حركة Git.
أما النسبة المتبقية، أي 0.00001% من المستودعات، فتطرح مشكلة أصعب. في البنية الحالية، تنتظر عملية الكتابة استجابة كل نسخة متماثلة سليمة، لذا فإن أبطأ نسخة تحدد الكمون والإنتاجية معًا. تبعد النسخة المتماثلة في منطقة Azure المستهدفة نحو 1000 ميل، وتتطلب كل كتابة عدة جولات ذهاب وإياب. يكمن الحل في تقليل التنسيق: تنطبق متطلبات اتساق Git على كل مرجع على حدة، وعادةً لا تعتمد تحديثات المراجع المختلفة على بعضها، لذلك لا يلزم تسلسلها.
المصدر: Hacker News · لخّصه HeadlinesBriefing