Timeout Pattern — tashqi service, database, file, queue yoki boshqa operation ma’lum muddat ichida tugamasa uni muvaffaqiyatsiz deb hisoblab, kutishni to‘xtatish yondashuvi. Timeout distributed tizimda cheksiz kutish, resource bandligi va cascading failure’ni kamaytiradi.
Network request “javob kelmadi” holatida qancha kutish kerakligi aniq bo‘lmasa thread, connection va user requestlari to‘planib qoladi.
Timeout turlari
Operationning turli bosqichlari uchun alohida timeout bo‘lishi mumkin:
- connect timeout;
- read timeout;
- write timeout;
- request timeout;
- idle timeout;
- transaction timeout;
- queue wait timeout;
- overall deadline.
Bitta umumiy qiymat barcha bosqich uchun bir xil ma’no bermaydi.
Connect timeout
Remote host bilan connection o‘rnatish uchun maksimal vaqt.
DNS resolution, TCP handshake va TLS handshake ayrim librarylarda alohida yoki birgalikda hisoblanishi mumkin.
Juda uzun connect timeout ishlamayotgan hostga ko‘p connection urinishini ushlab turadi.
Read timeout
Connection o‘rnatilgandan keyin response data’sini kutish muddati.
Server requestni qabul qilgan, ammo sekin ishlayotgan bo‘lishi mumkin.
Streaming response’da read timeout keyingi byte yoki butun response uchun turlicha talqin qilinadi.
Write timeout
Request body yoki data remote tomonga yuborilishi uchun maksimal vaqt.
Katta upload, sekin client yoki network congestion sabab write uzoq davom etishi mumkin.
Write timeout tugasa remote tomon requestning bir qismini olgan bo‘lishi ehtimoli bor.
Overall deadline
Butun operation uchun umumiy oxirgi vaqt.
Masalan, user requesti 2 soniyada tugashi kerak.
Ichki uchta downstream chaqiriq shu deadline ichida joylashadi.
Har child requestga mustaqil 2 soniya berish umumiy latency’ni 6 soniyaga chiqarishi mumkin.
Deadline propagation
Yuqori qatlam qolgan vaqtni downstream service’ga uzatadi.
Masalan:
client deadline = 2 s
gatewayda qolgan = 1.6 s
service’da qolgan = 1.2 s
database uchun = 0.8 s
Downstream o‘z operationini qolgan budjetdan uzoq bajarmaydi.
Timeout qiymatini tanlash
Qiymat real latency distributionga asoslanadi.
Kuzatiladi:
- median;
- p95;
- p99;
- network;
- dependency SLO;
- user expectation;
- retry budget.
Juda qisqa timeout sog‘lom requestlarni ham bekor qiladi.
Juda uzun timeout failure’ni kech aniqlaydi.
Timeout va retry
Timeoutdan keyin retry qilinishi mumkin, ammo original operation serverda davom etayotgan bo‘lishi ehtimoli bor.
Non-idempotent request qayta yuborilsa duplicate payment yoki order paydo bo‘lishi mumkin.
Idempotency key va operation statusi kerak.
Cancellation
Timeout faqat client kutishni to‘xtatishi mumkin.
Serverdagi operation avtomatik bekor bo‘lmasligi ehtimoli bor.
Cancellation signal protocol orqali uzatilsa server ishni to‘xtatishi mumkin.
Database query cancellation ham transaction holatini tekshirishni talab qiladi.
Resource cleanup
Timeoutdan keyin:
- connection;
- cursor;
- file;
- thread;
- transaction;
- temporary buffer
tozalanishi kerak.
Connection poolga buzilgan yoki noaniq holatdagi connection qaytarilmaydi.
Cascading failure
Bir service sekinlashsa upstream requestlar kutadi.
Thread va connectionlar tugaydi.
Keyin sog‘lom dependency’lar ham request ololmay qoladi.
Timeout failure’ni tez chegaralaydi.
Circuit breaker va bulkhead bilan birga ishlatilishi mumkin.
Queue timeout
Task queue’da operation juda uzoq kutsa business ma’nosini yo‘qotishi mumkin.
Masalan, real-time notification 30 daqiqadan keyin foydasiz.
Queue message expiration yoki task deadline bilan cheklanadi.
Database timeout
Database’da:
- connection acquisition;
- statement;
- lock wait;
- transaction
uchun alohida timeout bo‘lishi mumkin.
Lock timeout bilan query execution timeout bir xil emas.
Uzoq query bekor qilingach transaction rollback talab qilishi mumkin.
Lock timeout
Transaction resource lockini ma’lum vaqtgacha kutadi.
Timeout tugasa statement xato beradi.
Bu deadlock detectiondan farq qiladi.
Deadlock cycle aniqlanganda database transactionlardan birini tezroq abort qilishi mumkin.
Idle timeout
Connection ma’lum vaqt traffic bo‘lmasa yopiladi.
Load balancer, proxy va server idle timeoutlari bir-biriga mos bo‘lishi kerak.
Aks holda client pool o‘lik connectionni qayta ishlatishga urinadi.
Streaming
Uzoq streamda overall timeout bo‘lmasligi, ammo idle timeout bo‘lishi mumkin.
Masalan, har 30 soniyada heartbeat kelishi kerak.
Heartbeat yo‘qolsa connection uziladi.
Cheksiz stream cancellation va reconnect strategiyasiga ega.
Fallback
Timeout yuz bersa:
qaytarilishi mumkin.
Fallback data freshness va correctness talabiga mos bo‘lishi kerak.
Observability
Timeout metriclari operation va dependency bo‘yicha ajratiladi.
Logda:
- configured timeout;
- elapsed time;
- remaining deadline;
- dependency;
- retry soni;
- cancellation holati
ko‘rsatiladi.
“Connection error” ichida timeoutni yashirish tahlilni qiyinlashtiradi.
Test
Testlar:
- dependency umuman javob bermaydi;
- deadline yaqin;
- timeoutdan keyin cleanup;
- retry duplicate yaratmaydi;
- cancellation;
- partial response;
- slow stream;
- lock wait
holatlarini qamrab oladi.
Budget taqsimoti
Bir request ichida connection, server processing va response read uchun alohida vaqt budjeti beriladi.
Barcha budjetlar umumiy deadline’dan oshmaydi.
Qolgan vaqt juda kam bo‘lsa yangi downstream call boshlamasdan tez fallback qaytarish mumkin.
Tail latency
Dependency requestlarining kichik qismi juda sekin bo‘lsa p99 umumiy service latency’sini belgilaydi.
Timeout o‘rtacha qiymatga emas, tail distribution va error budgetga asoslanadi.
Hedged request ayrim read-only holatlarda yordam berishi mumkin, ammo loadni oshiradi.
Timeout propagation testi
Integration testda gatewaydan databasegacha deadline metadata’si kuzatiladi.
Qaysi qatlam timeoutni uzaytirib yuborgani yoki default qiymat bilan almashtirgani aniqlanadi.
Bog‘liq tushunchalar
Deadline, Connect timeout, Read timeout, Cancellation, Retry, Circuit breaker, Bulkhead, Cascading failure, Idempotency, Distributed system