Multi-region architecture — application komponentlari va ma’lumotlar bir nechta geografik cloud regionga joylashtirilgan tizim tuzilishi. Uning maqsadi global foydalanuvchiga yaqin xizmat ko‘rsatish, butun region uzilishiga chidamlilik yoki data residency talablarini bajarish bo‘lishi mumkin. Bir xil resursni ikki regionda yaratishning o‘zi to‘liq arxitektura bermaydi; trafik, holat va failover muvofiqlashtiriladi.
Joylashtirish modellari
Active-passive modelda asosiy region trafikni qabul qiladi, ikkinchi region recovery uchun saqlanadi. Cold standby’da faqat backup va deklaratsiya bor; warm standby’da qisqartirilgan compute ishlaydi; hot standby deyarli to‘liq capacity bilan tayyor turadi. Tayyorlik oshgani sari xarajat ham oshadi.
Active-active modelda ikki yoki undan ko‘p region bir vaqtda request bajaradi. Stateless web qatlamini ko‘paytirish nisbatan oson, lekin session, queue va database write’larini kelishtirish murakkab. Global load balancer foydalanuvchini sog‘lom va yaqin endpointga yo‘naltiradi.
Ma’lumot strategiyasi
Single-writer model barcha write’larni bitta home regionga yuboradi, boshqa regionlarda read replica ishlaydi. U conflictni kamaytiradi, ammo uzoq foydalanuvchi write latency’sini oshiradi. Multi-writer model local write beradi, lekin bir yozuv ikki regionda o‘zgarsa conflict resolution talab qiladi.
Strong consistency uchun regionlararo synchronous quorum commit latency va partition paytida availabilityga ta’sir qiladi. Asynchronous replication pastroq latency beradi, ammo failoverda so‘nggi yozuvlar yo‘qolishi mumkin. RPO va RTO tanlovni belgilaydi.
Tenant yoki key bo‘yicha geo-partitioning har ma’lumotni bitta home regionga joylashtirib, global routing bilan topadi. Bu residencyga mos, lekin cross-tenant query va region ko‘chirish jarayonini murakkablashtiradi.
Global trafik
DNS-based routing TTL va resolver cache sabab failoverni bir zumda bajarmaydi. Anycast yoki global proxy tez health-based steering berishi mumkin. Health check faqat /health javobini emas, regionning database va queuega yozish qobiliyatini ham aks ettirishi kerak.
Client retry eski va yangi regionga bir requestni yuborishi mumkin. Idempotency key duplicate biznes amalini cheklaydi. Sticky session failover paytida yo‘qolishi mumkin; session shared store yoki token ichida saqlanadi.
Deploy va konfiguratsiya
Artifact barcha regionga bir xil digest bilan chiqariladi, environmentga xos endpoint va secret deklarativ konfiguratsiyada beriladi. Schema migration regionlar turli application versiyada turgan davrga backward-compatible bo‘ladi. Canary bir regionda boshlanishi mumkin, ammo regionga xos traffic va data pattern natijani cheklashi mumkin.
Infrastructure dependencylar inventory qilinadi: certificate, DNS, identity, container registry va monitoring control plane’ning o‘zi bitta regionga bog‘lanib qolmasligi kerak.
Sinov va operatsiyalar
Failover faqat hujjatda emas, muntazam mashqda tekshiriladi. Region route’i olib tashlanib, capacity scale, replication lag, data reconciliation va failback o‘lchanadi. Failback ko‘pincha failoverdan murakkab: eski primary qaytganda qaysi yozuv authoritative ekanini aniqlash kerak.
Observability metric va loglarni markazlashtiradi, ammo monitoring backendning failure domain’i alohida bo‘ladi. Har event region, replica role va request ID bilan belgilanadi. Xarajat hisobida doimiy standby, cross-region replication va egress ham bor.
Clock va identifikatorlar
Regionlar soati mukammal teng emas. Global orderingni wall clock timestampning o‘ziga bog‘lash zid ketma-ketlik yaratishi mumkin. Database logical clock, sequence allocation yoki globally unique identifier ishlatadi. Bir region markaziy ID service’ga bog‘lansa uning uzilishi boshqa regionda yangi obyekt yaratishni to‘xtatadi; ID strategiyasi partition holatini hisobga oladi.
Bog‘liq tushunchalar
Cloud region, Active-active, Active-passive, Global load balancing, Data replication, Disaster recovery, RPO, RTO