GitHub جزئیات معماری تازه ذخیره‌سازی Git خود، Rubicon، را منتشر کرده است. به گفته شرکت، آزمایش داخلی نشان داده که این معماری می‌تواند از فعالیت هم‌زمان ۵۰۰۰ agent روی یک repository و ارسال ۷۲۰۰ push در ثانیه پشتیبانی کند و هم‌زمان درخواست‌های خواندن را با latency پایین و پایدار پاسخ دهد. این اعداد نتیجه آزمایش داخلی‌اند، نه گزارشی از ترافیک معمول GitHub.com.
اصل طراحی Rubicon، کاهش هماهنگی و جداکردن storage از compute است. داده‌های Git از نوع Immutable Object هستند و نامشان از محتوایشان می‌آید؛ بنابراین چند نویسنده می‌توانند آن‌ها را بدون توافق با یکدیگر ذخیره کنند. بخش نیازمند توافق، تغییر Git Reference است که در مقایسه با داده‌های یک push بسیار کوچک است. همین تفاوت اجازه می‌دهد ذخیره‌سازی، پاسخ‌گویی به درخواست‌ها و نگهداری repository مستقل از هم مقیاس بگیرند.
در معماری جدید، Spokes همچنان routing، load balancing و تقسیم ترافیک را بر عهده دارد. درخواست‌ها به گروه کوچکی از virtual replicaها می‌رسند که می‌توانند خواندن، نوشتن یا هر دو را انجام دهند. دیسک محلی آن‌ها فقط یک cache قابل بازسازی است؛ درستی عملکرد به رسیدن درخواست به یک replica مشخص وابسته نیست. با افزایش ترافیک یک repository نیز می‌توان virtual replica بیشتری اضافه کرد.
داده ماندگار در دو محل نگهداری می‌شود: objectهای Git در قالب pack داخل Azure Blob Storage قرار می‌گیرند؛ Git Referenceها و فهرست packهای repository در سرویس replicated log جداگانه‌ای به نام Ref-CAS ثبت می‌شوند. هنگام نوشتن، virtual replica ابتدا pack ورودی را index و در Blob Storage بارگذاری می‌کند؛ سپس با یک transaction در Ref-CAS، هم فهرست packها و هم Git Referenceها را تغییر می‌دهد. هنگام خواندن، نسخه Git Reference بررسی می‌شود و فقط packهای موردنیاز وارد cache می‌شوند.
Compaction نیز به nodeهای جداگانه سپرده شده است. آن‌ها در پس‌زمینه packها را ادغام و objectهای دسترس‌ناپذیر را حذف می‌کنند؛ این کار روی virtual replica انجام نمی‌شود. برای توسعه‌دهنده، شیوه push، fetch و branch و حفاظت‌های موجود تغییر نمی‌کند.
