ספליטגייט פירסמו התנצלות לפני מספר ימים בחשבון הטוויטר שלהם בזו הלשון (תרגום שלי):

בילינו את כל הלילה באופטימיזציות אבל אחרי שיחה עם AWS גילינו שבסיס הנתונים שלנו (רדיס) יכול להתמודד רק עם 65,536 שחקנים במקביל. אנחנו עובדים על פיתוח מערכת תור קטנה שתגביל את מספר השחקנים ל 65K עד שנתגבר על מגבלה זו.

כמובן שהבעיה היא לא רדיס אלא איך שהם משתמשים ברדיס, וכמובן שהמגבלה היתה שם עוד לפני שהם כתבו את שורת הקוד הראשונה. מחקר טוב היה יכול לחסוך להם את הפאדיחה, אבל גם למחקר טוב יש עלות. ולכן שתי הגישות:

1. אנחנו יכולים להחליט לעשות את כל המחקר מבעוד מועד, לבדוק עומסים, לייצר Deployments מדורגים ובעיקר לקרוא וללמוד הרבה מאוד לפני שמחליטים על ארכיטקטורה, טכנולוגיה ושיטת עבודה.

2. או שאנחנו יכולים לרוץ מהר ולשבור דברים, ללמוד מספיק רק בשביל להרים את הגירסה הבאה ולהיות מוכנים להתנצל ולתקן כשדברים באמת נשברים.

הסכנה בגישה הראשונה היא שבמקום לכתוב קוד ולהעלות מוצרים אנחנו ניתקע כל היום ללמוד ולקרוא ולבדוק עוד מקרי קצה במסלול אינסופי; הסכנה בגישה השניה היא שנפספס דברים מאוד מרכזיים בארכיטקטורה בגלל דברים שהיינו צריכים לדעת. והקסם יהיה במציאת דרך האמצע שמתאימה למערכת ולסגנון העבודה שלכם.