Gateway Aggregation — clientga kerakli ma’lumotni bir nechta backend service’dan yig‘ib, bitta umumiy response sifatida qaytaradigan cloud va microservice pattern. Aggregation API gateway, Backend for Frontend yoki maxsus composition service’da bajarilishi mumkin.
Pattern clientning ko‘p tarmoq chaqiriqlarini kamaytiradi va response compositionni server tomoniga ko‘chiradi.
Muammo
Bitta product sahifasi uchun client quyidagilarni chaqirishi mumkin:
Mobil client beshta request yuborsa latency, battery va error handling murakkablashadi.
Gateway bitta requestda bu natijalarni yig‘adi.
Aggregator
Aggregator client requestini qabul qiladi.
U:
- kerakli backendlarni aniqlaydi;
- requestlarni parallel yoki ketma-ket yuboradi;
- natijalarni map qiladi;
- umumiy response yaratadi;
- partial failure siyosatini qo‘llaydi.
Aggregator business source of truth bo‘lmasligi kerak.
Parallel call
Mustaqil backend requestlari parallel yuboriladi.
Umumiy latency eng sekin dependencyga yaqin bo‘ladi.
Ketma-ket chaqiriqda esa latencylar qo‘shiladi.
Dependency natijasi keyingi request uchun kerak bo‘lsa ayrim qadamlar ketma-ket qoladi.
Response composition
Turli service response’lari clientga qulay contractga aylantiriladi.
Masalan:
{
"product": {},
"price": {},
"stock": {},
"reviews": []
}
Tashqi backend fieldlari to‘g‘ridan-to‘g‘ri client contractiga tarqalmasligi kerak.
Backend for Frontend
Web, mobile va admin clientlar turli data shakliga ehtiyoj sezishi mumkin.
Har client turi uchun alohida BFF aggregator yaratiladi.
Bu umumiy gateway ichida juda ko‘p client-specific condition yig‘ilishini kamaytiradi.
Timeout
Har dependency uchun alohida timeout belgilanadi.
Gatewayning umumiy deadline’i ham mavjud.
Agar umumiy request 2 soniyada tugashi kerak bo‘lsa bir dependency 5 soniya kuta olmaydi.
Qolgan vaqt downstream requestlarga taqsimlanadi.
Partial failure
Bir backend ishlamasa butun response fail qilishi shart emas.
Masalan, recommendation unavailable bo‘lsa product va price qaytarilishi mumkin.
Response:
bilan qaytadi.
Payment yoki authorization kabi kritik dependency uchun partial response mumkin emas.
Fallback
Fallback variantlari:
Fallback noto‘g‘ri ma’lumotni “yangi” deb ko‘rsatmasligi kerak.
Freshness metadata foydali.
Error mapping
Backend errorlari client contractiga moslashtiriladi.
Gateway internal service nomi va stack trace’ni oshkor qilmaydi.
Kritik va optional dependency xatolari ajratiladi.
Retry
Faqat transient va idempotent requestlar retry qilinadi.
Gateway barcha backend requestlarini ko‘r-ko‘rona retry qilsa outage vaqtida loadni oshiradi.
Retry budget va exponential backoff ishlatiladi.
Circuit breaker
Muammoli backendga chaqiriqlar vaqtincha to‘xtatiladi.
Gateway tez fallback qaytaradi.
Circuit holati dependency va operation bo‘yicha ajratiladi.
Bitta endpoint xatosi butun service’ni bloklamasligi mumkin.
Cache
Aggregation natijasi yoki alohida backend response’lari cache qilinishi mumkin.
- user;
- locale;
- permission;
- product ID;
- version
ni hisobga oladi.
Personal response’ni umumiy cache’da saqlash data leak yaratishi mumkin.
Authentication
Gateway clientni autentifikatsiya qiladi va identity’ni backendga xavfsiz uzatadi.
Backend gatewaydan kelgan headerga ko‘r-ko‘rona ishonmasligi uchun mTLS, signed token yoki trusted network ishlatiladi.
Authorization qaysi qatlamda bajarilishi aniq belgilanadi.
Over-fetching
Gateway clientga kerak bo‘lmagan katta backend response’larini olib kelishi mumkin.
Projection, field selection va maxsus endpointlar bilan data hajmi kamaytiriladi.
Aks holda aggregation faqat client networkini backend networkiga ko‘chiradi.
N+1 service call
Ro‘yxatdagi har item uchun alohida backend request yuborish distributed N+1 muammosini yaratadi.
Masalan, 100 product uchun 100 pricing request.
Batch endpoint yoki bulk query ishlatiladi.
Availability
Gateway ko‘p dependencyga bog‘langan sari umumiy muvaffaqiyat ehtimoli pasayadi.
Optional dependency, cache va partial response availabilityni oshiradi.
Gatewayning o‘zi ham high availability bilan deploy qilinadi.
Observability
Har client request uchun distributed trace yaratiladi.
Kuzatiladi:
- umumiy latency;
- har dependency latency’si;
- timeout;
- fallback;
- partial response;
- payload hajmi;
- cache hit.
O‘rtacha qiymat eng sekin dependency tail latency’sini yashirmasligi kerak.
Versionlash
Backend service’lar mustaqil versionlanadi.
Aggregator ichki mapping orqali client contractini barqaror saqlaydi.
Client API o‘zgarsa alohida version yoki backward-compatible field qo‘shish ishlatiladi.
Kamchiliklari
Gateway business logic markaziga aylanib ketishi mumkin.
Ko‘p backendga bog‘liqlik deployment va testni murakkablashtiradi.
Katta payload va fan-out gateway resource’ini sarflaydi.
Har use case uchun aggregation zarur emas.
Response deadline
Gateway har dependency javobini kutib umumiy deadline’dan oshmasligi kerak.
Optional service uchun qisqaroq timeout beriladi.
Kritik service uchun qolgan vaqt saqlanadi.
Deadline tugagach hali ishlayotgan child requestlarga cancellation yuboriladi.
Schema ownership
Yakuniy response contractining egasi gateway yoki BFF jamoasi bo‘ladi.
Backend service o‘z internal DTO’sini o‘zgartirishi mumkin, ammo aggregator mapping orqali client contractini saqlaydi.
Bu mapping integration test bilan himoyalanadi.
Payload streaming
Juda katta birlashtirilgan response gateway memory’sida to‘liq yig‘ilmasligi kerak.
Streaming mumkin bo‘lsa bo‘limlar bosqichma-bosqich uzatiladi.
Lekin JSON kabi formatda partial failure va client parsing semantikasi oldindan belgilanadi.
Bog‘liq tushunchalar
API Gateway, Backend for Frontend, Response composition, Fan-out, Partial failure, Circuit breaker, Timeout, Microservices, Distributed tracing