בהתחלה עובדים עם מכונה אחת שעושה גם WEB (ז"א מריצה IIS, אפצ'י וכו') וגם עושה DB.
כשגדלים כדאי (לרוב) לפצל בינהם כך שיהיו שרתים ייעודים ל-WEB ול-DB ישנן אפשרויות לפיצולים נוספים, תלוי בסוג האתר*.
באשר ל-DB, אחרי שמוציאים אותו למכונה ייעודית וזה כבר לא מספיק, הצורה "הפשוטה" תהיה לעבוד עם שרת master אחד שאליו כותבים, ומספר שרתי slave שמהם קוראים מידע. כל זה עם הגדרה של ריפליקציה כך שהמידע שנכתב למאסטר יתעדכן בשרתי הסלייב.
כשאתרים גדלים יותר ויותר, נוצרים צווארי בקבוק מסויימים, שאילתות שמתחילות להיות מאוד כבדות וכו'. אפשר לנסות לצמצם את כמות הגישות ל-DB ולבצע קאשינג ע"י האפליקציה עצמה. כמו כן לפעמים כדאי שקול מחדש את עיצוב הטבלאות ולבדוק אם אפשר לסדר את המידע בצורה יעילה. אולי כדאי לפצה לכמה בסיסי נתונים שונים וכו'.
בכל אופן, כל אתר גדול שובר את הראש בצורה אחרת מבחינת ה-DB שלו. מה יהיה יותר נכון בהתאם לאופי האתר, המידע שהוא מחזיק ואיך שהוא צריך להגיש. לפעמים יש חשיבות לכך שהמידע תמיד יהיה מאוד מעודכן, מנגד יש אתרים שלא נורא אם יהיה קצת דיליי במידע.
באשר ל-WEB, כאן זה יחסית פשוט. תוך שימוש ב-load balancer ניתן לווסת את התנועה בין כמה שרתי WEB שונים ותלוי בהגדרות, אפשר להגיע ליתירות גבוהה כך שבמידה ואחד השרתים נופל התנועה מועברת אוטומטית לשרתים אחרים.
* לדוגמה כאשר מדובר בשרת שמגיש הרבה תמונה, יהיה הגיוני להשתמש ב-CDN, שרת קאשינג או ב-file server.
כל זה ממש ממש ממש על קצה המזלג.
לקריאה נוספת, איך השמות הגדולים עושים את זה, תוכל לבדוק באתר הזה שמכסה דיי הרבה חברות ענק ומספר על הארכיטקטורה שלהם -
highscalability.com