אני מבין התיאור ואת הנקודה שלך. עכשיו אנחנו צריכים לברר איך זה נניח לעבודה טכנית.
אני רואה כאן בעיה אחת היא כיצד אנו יזהה כי יש לנו כבר מגבלות זמין לאחר אלה כאשר הגיע לפני.
אנחנו פשוט כל הזמן שואלים ספק מועדף, לאחר מכן עבור השלב הבא. זה עולה ביצועים - מכיוון עבור כל בקשה בדף המחייב תרגום, שעשינו שיחה מצליחה לספק מועדף, אחת מכן הבאה (כך הוא יכול להיות מספר פניות נכשלת כאשר vBET יתמכו יותר ממשקי Api).
פתרון אחר יהיה לאחסן מידע ספק מועדף זה אינה זמינה ועבור ישירות לשקופית הבאה. זה יהיה הרבה יותר מהר, כי בדיקת משתנה מקומי הוא מהיר הרבה יותר ממתין לתגובה משרת חיצוני. הפעם יש לנו בעיה אחרת - איננו יודעים כאשר ספק מועדף זמין. אנחנו יכולים וכמובן כמה משימה מתוזמנת אשר לבקש תרגום (קצר) לדוגמה פעם אחת ליום/לשעה כדי לבדוק אותה. אז באסטרטגיה זו יש לנו להחליט באיזו תדירות כברירת מחדל פעילות כזו נניח לעבוד. כמובן שאנו להכניס אותו רק כאשר יש ספק מסומן כלא זמינות.
גם אם אנחנו מציינים ספקי כלא זמין - מה לעשות כאשר אנו יודעים כי כל הספקים אינם זמינים - הוספת מידע מסוים עבור משתמש הקצה או רק מה לתרגם הוא המטמון ואת השאר בשם המקורי, ללא כל מידע נוסף אודות חוסר זמני של ספקי תרגום.
ללא תלות באופן בו יבוצע, גוגל תהיה כאל אחד API (v1 או v2 בהתאם לתצורה) - אין טעם לפצל אותו, כי גוגל v1 ייסגרו בקרוב מאוד.
דבר נוסף הוא לאפשר קביעת תצורה של ספקי תור עבור כל זוג שפה בנפרד. ברגע זה vBET כבר מאפשר קביעת תצורה של ספק תרגום עבור כל זוג של השפה. אני חושב כי אנו יכולים לשנות אותה מכל ערך אחד על ערכים מופרדים בפסיקים (CSV). ככה נדע עבור כל זוג שפה אילו ספקים תומכת תרגום זה, מה הן העדפות סדר (רק סדר ברשימת CSV).
לתשומת לבכם: זו תהיה השפעה ביצועים מסוימות בכל מקרה. במקום ליצור אובייקט אחד עבור תרגום נצטרך ליצור מערך של אובייקטים ואובייקט גלישה נוספים כאלה (כדי להפוך אותה לשקופה עבור חלקים אחרים של קוד ופחות באגים מועדים). כמובן אנו יוצרים אובייקטים לא עבור ספקי שאנו יודעים אינם זמינים ברגע זה.
פתרון זה יהיה להגדיר מחדש לביצועים טובים יותר ולהסיר ספקי תור - בדיוק כמו שהוא עכשיו - ספק אחד לכל צמד שפות.
זה לא אמור להיות יקר עבור ביצועים, אך עדיין חלק נוסף לוגיקה זיכרון וצריכת.
ספרי איזה פתרון עדיף.