HTTP 429 (\u00c7ok Fazla \u0130stek) hatalar\u0131 sonras\u0131nda yap\u0131lan otomatize retry i\u015flemleri, arka planda ba\u015far\u0131yla tamamlanm\u0131\u015f batch i\u015flerinin tekrarlanmas\u0131na ve ciddi veri kirlili\u011fine yol a\u00e7abilir. Bu makalede, bu kronik mimari sorunu idempotent tasar\u0131mlar, Ak\u0131ll\u0131 Yeniden Deneme (Smart Retry) mekanizmalar\u0131 ve da\u011f\u0131t\u0131k kilitler kullanarak nas\u0131l k\u00f6kten \u00e7\u00f6zece\u011finizi ad\u0131m ad\u0131m inceliyoruz.<\/p>\n
Mikrohizmet mimarilerinde (microservices architecture) veya d\u0131\u015f API entegrasyonlar\u0131nda toplu veri i\u015fleme (batch processing) yaparken s\u0131kl\u0131kla Oran S\u0131n\u0131rlamas\u0131 (Rate Limiting) mekanizmalar\u0131 ile kar\u015f\u0131la\u015f\u0131r\u0131z. Hedef sunucu, sistem kaynaklar\u0131n\u0131 korumak amac\u0131yla belirli bir zaman diliminde kabul edebilece\u011fi istek say\u0131s\u0131n\u0131 s\u0131n\u0131rlar. Bu s\u0131n\u0131r a\u015f\u0131ld\u0131\u011f\u0131nda ise istemciye \u00d6zellikle arka plan i\u015flerinde (background jobs) istemci yaz\u0131l\u0131mlar\u0131, Bu durum yaz\u0131l\u0131m sistemlerinde \u015fu kritik sorunlara yol a\u00e7ar:<\/p>\n Geli\u015ftirdi\u011fimiz bir e-ticaret platformunda, gece yar\u0131s\u0131 \u00e7al\u0131\u015fan bir batch i\u015fi (cron job) arac\u0131l\u0131\u011f\u0131yla son 24 saatte al\u0131\u015fveri\u015f yapan kullan\u0131c\u0131lar\u0131n hesaplar\u0131na tan\u0131mlanacak sadakat puanlar\u0131n\u0131 i\u015fliyorduk. Sistem, her biri 500 kullan\u0131c\u0131 i\u00e7eren paketler halinde API’ye istek at\u0131yordu. Mimarimizde Axios tabanl\u0131 bir HTTP istemcisi ve ba\u015far\u0131s\u0131z isteklerde 3 kez yeniden deneme yapan varsay\u0131lan bir retry politikas\u0131 (retry policy) bulunuyordu.<\/p>\n Bir gece, veri taban\u0131 yo\u011funlu\u011fundan dolay\u0131 API Gateway katman\u0131m\u0131z yan\u0131t s\u00fcrelerini uzatt\u0131 ve istemciye Sabah kar\u015f\u0131la\u015ft\u0131\u011f\u0131m\u0131z tablo olduk\u00e7a \u00fcrk\u00fct\u00fcc\u00fcyd\u00fc:<\/p>\n Bu kriz bize a\u00e7\u0131k\u00e7a g\u00f6sterdi ki; ba\u015far\u0131s\u0131z g\u00f6r\u00fcnen bir HTTP iste\u011fi, asl\u0131nda sunucuda ba\u015far\u0131l\u0131 olmu\u015f olabilir. A\u011f katman\u0131ndaki belirsizli\u011fi hesaba katmadan yap\u0131lan basit retry stratejileri, sistemin en b\u00fcy\u00fck d\u00fc\u015fman\u0131d\u0131r.<\/p>\n Da\u011f\u0131t\u0131k sistemlerde (distributed systems) en zorlay\u0131c\u0131 problemlerden biri “A\u011f B\u00f6l\u00fcnmesi” (Network Partition) ve belirsizlik durumudur. Bir HTTP iste\u011fi ba\u015flat\u0131ld\u0131\u011f\u0131nda s\u00fcre\u00e7 \u00fc\u00e7 ana a\u015famadan ge\u00e7er: \u0130stemcinin iste\u011fi g\u00f6ndermesi, sunucunun iste\u011fi i\u015flemesi ve sunucunun yan\u0131t\u0131 geri g\u00f6ndermesi. A\u011f \u00fczerindeki herhangi bir kesinti veya oran s\u0131n\u0131rlay\u0131c\u0131 (rate limiter) m\u00fcdahalesi genellikle \u00fc\u00e7\u00fcnc\u00fc a\u015famada, yani yan\u0131t d\u00f6nerken ger\u00e7ekle\u015fir.<\/p>\n Sunucu taraf\u0131nda i\u015flem M\u00fckerrer i\u015fleme sorununu \u00e7\u00f6zmenin temel ta\u015f\u0131 E\u015fg\u00fc\u00e7l\u00fcl\u00fck (Idempotency) ilkesidir. Matematiksel ve bilgisayar bilimleri anlam\u0131nda idempotency; bir i\u015flemin bir kez uygulanmas\u0131 ile birden fazla kez uygulanmas\u0131 durumunda sistemde ayn\u0131 nihai sonucun \u00fcretilmesidir. HTTP metotlar\u0131ndan Batch i\u015flerimizde Sunucu taraf\u0131ndaki s\u00fcre\u00e7 \u015fu \u015fekilde i\u015fler:<\/p>\n Sadece Idempotency Key kullanmak yeterli de\u011fildir. E\u011fer istemci bir Bunu \u00f6nlemek i\u00e7in iki temel algoritmay\u0131 birle\u015ftirmeliyiz:<\/p>\n 1. \u00dcstel Bekleme (Exponential Backoff):<\/strong> Her ba\u015far\u0131s\u0131z denemeden sonra bekleme s\u00fcresini katlayarak art\u0131rma y\u00f6ntemidir. \u00d6rne\u011fin ilk ba\u015far\u0131s\u0131zl\u0131kta 1 saniye, ikincisinde 2 saniye, \u00fc\u00e7\u00fcnc\u00fcs\u00fcnde 4 saniye beklenir.<\/p>\n 2. Rastgele Sapma (Jitter):<\/strong> Bekleme s\u00fcrelerinin tamamen ayn\u0131 olmas\u0131n\u0131 engelleyen k\u00fc\u00e7\u00fck rastgele zaman dilimleridir. T\u00fcm i\u015f\u00e7ilerin (workers) ayn\u0131 saniyede tekrar istek atmas\u0131n\u0131 engeller ve trafik y\u00fck\u00fcn\u00fc zamana yayar.<\/p>\n Matematiksel olarak Jitter i\u00e7eren bekleme s\u00fcresi form\u00fcl\u00fc \u015fu \u015fekildedir:<\/p>\n A\u015fa\u011f\u0131daki Node.js ve TypeScript \u00f6rne\u011finde, hem Yukar\u0131daki kod blo\u011funda g\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, istemci ka\u00e7 kez retry yaparsa yaps\u0131n, sunucuya her zaman ayn\u0131 Sadece HTTP seviyesinde \u00f6nlem almak baz\u0131 durumlarda yetersiz kalabilir. Ya ayn\u0131 batch i\u015fi iki farkl\u0131 arka plan i\u015f\u00e7isi (worker instance) taraf\u0131ndan e\u015fzamanl\u0131 olarak tetiklenirse? Veya ilk istek hen\u00fcz sunucuda i\u015flenirken (pending durumundayken) istemci zaman a\u015f\u0131m\u0131na u\u011fray\u0131p ikinci iste\u011fi g\u00f6nderirse?<\/p>\n Bu gibi durumlar yar\u0131\u015f ko\u015fuluna (race condition) yol a\u00e7ar. \u00c7\u00f6z\u00fcm, sunucu taraf\u0131nda Da\u011f\u0131t\u0131k Kilitleme (Distributed Locking)<\/strong> mekanizmas\u0131 kurmakt\u0131r. Redis tabanl\u0131 Sunucu taraf\u0131ndaki i\u015flem ak\u0131\u015f\u0131 \u015fu ad\u0131mlarla g\u00fcvenli hale getirilir:<\/p>\n Bu mimari yap\u0131 sayesinde, HTTP 429 hatas\u0131 nedeniyle a\u011fda kalan istekler retry edildi\u011finde, sunucu ya i\u015flemi kilit sayesinde bekletir ya da tamamlanm\u0131\u015f sonucu veritaban\u0131na dokunmadan mili saniyeler i\u00e7inde istemciye geri d\u00f6ner.<\/p>\n Bu mimari d\u00f6n\u00fc\u015f\u00fcm\u00fc tamamlad\u0131ktan sonra sistemlerimizde elde etti\u011fimiz somut verileri ve kazan\u0131mlar\u0131 \u015fu \u015fekilde s\u0131ralayabiliriz:<\/p>\n Da\u011f\u0131t\u0131k sistemlerde hata ka\u00e7\u0131n\u0131lmazd\u0131r. A\u011f kesintileri, ge\u00e7ici sunucu yo\u011funluklar\u0131 ve Batch i\u015flerinizi g\u00fcvene almak istiyorsan\u0131z, basit d\u00f6ng\u00fcsel retry mant\u0131klar\u0131n\u0131 derhal terk etmelisiniz. Bunun yerine istemci taraf\u0131nda Exponential Backoff ve Jitter<\/strong>, sunucu taraf\u0131nda ise Idempotency Key ve Distributed Lock<\/strong> desenlerini bir arada kullanmal\u0131s\u0131n\u0131z. Ancak bu b\u00fct\u00fcnsel yakla\u015f\u0131mla veri kayb\u0131 ve veri kirlili\u011fi ya\u015famadan \u00f6l\u00e7eklenebilir sistemler in\u015fa edebilirsiniz.<\/p>\n \u0130stemci taraf\u0131ndan bunu %100 kesinlikle anlamak imkans\u0131zd\u0131r. A\u011f katman\u0131ndaki belirsizlik nedeniyle iste\u011fin sunucuya ula\u015f\u0131p yan\u0131t\u0131n m\u0131 yolda kald\u0131\u011f\u0131, yoksa iste\u011fin hi\u00e7 ula\u015fmad\u0131\u011f\u0131 m\u0131 bilinemez. Bu belirsizli\u011fi y\u00f6netmenin tek yolu istemci taraf\u0131nda her iste\u011fe bir Bu s\u00fcre i\u015f mant\u0131\u011f\u0131n\u0131za (business logic) g\u00f6re de\u011fi\u015fir. Genellikle batch i\u015flerin yeniden deneme pencereleri dikkate al\u0131narak Idempotency anahtarlar\u0131 Redis gibi bellek i\u00e7i veri depolar\u0131nda 24 ila 72 saat aras\u0131nda saklan\u0131r. S\u00fcre doldu\u011funda anahtar otomatik olarak silinebilir.<\/p>\n \u00d6nerilen ideal retry say\u0131s\u0131 genellikle 3 ile 5 aras\u0131ndad\u0131r. \u00c7ok y\u00fcksek retry say\u0131lar\u0131 (\u00f6rne\u011fin 10 ve \u00fczeri), sistem \u00fczerindeki birikmi\u015f y\u00fck\u00fc art\u0131rabilir. E\u011fer bir i\u015f 5 denemeden sonra hala 429 hatas\u0131 al\u0131yorsa, ilgili batch i\u015fini \u00d6l\u00fc Mektup Kuyru\u011funa (Dead Letter Queue – DLQ) ta\u015f\u0131y\u0131p insan m\u00fcdahalesine sunmak daha sa\u011fl\u0131kl\u0131 bir yakla\u015f\u0131md\u0131r.<\/p>\n E\u011fer 100 farkl\u0131 arka plan i\u015f\u00e7isi ayn\u0131 anda 429 hatas\u0131 al\u0131rsa ve sabit bir \u00fcstel bekleme s\u00fcresi (\u00f6rne\u011fin hepsi tam 2 saniye) kullan\u0131rsa, 2 saniye sonra 100 i\u015f\u00e7i tekrar ayn\u0131 anda sunucuya y\u00fcklenir. Jitter, bu 100 i\u015f\u00e7inin iste\u011fini 2.1s, 2.4s, 2.05s gibi farkl\u0131 zaman dilimlerine yayarak sunucunun \u00fczerindeki anl\u0131k y\u00fck patlamas\u0131n\u0131 engeller.<\/p>\n #Teknoloji #WebGeli\u015ftirme #SoftwareArchitecture #Microservices #Backend<\/p>\nHTTP 429 Too Many Requests<\/code> yan\u0131t\u0131 d\u00f6nd\u00fcr\u00fcl\u00fcr. Teoride bu durum son derece sa\u011fl\u0131kl\u0131d\u0131r; ancak i\u015fin i\u00e7ine otomatik yeniden deneme (retry) mekanizmalar\u0131 girdi\u011finde s\u00fcre\u00e7 bir felakete d\u00f6n\u00fc\u015febilir.<\/p>\nHTTP 429<\/code> yan\u0131t\u0131n\u0131 ald\u0131klar\u0131nda iste\u011fin tamamen ba\u015far\u0131s\u0131z oldu\u011funu varsayar. Oysa ger\u00e7ek d\u00fcnyada a\u011f ileti\u015fimi tek y\u00f6nl\u00fc de\u011fildir. Sunucu iste\u011fi alm\u0131\u015f, veri taban\u0131 i\u015flemini (database transaction) ba\u015far\u0131yla tamamlam\u0131\u015f ancak yan\u0131t\u0131 d\u00f6nd\u00fcr\u00fcrken oran s\u0131n\u0131r\u0131na tak\u0131lm\u0131\u015f veya bir zaman a\u015f\u0131m\u0131 (timeout) ya\u015fam\u0131\u015f olabilir. \u0130stemci ayn\u0131 batch y\u00fck\u00fcn\u00fc tekrar g\u00f6nderdi\u011finde, e\u011fer hedef sistem e\u015fg\u00fc\u00e7l\u00fc (idempotent) tasarlanmam\u0131\u015fsa, ayn\u0131 veri k\u00fcmesi veri taban\u0131na m\u00fckerrer (duplicate) olarak i\u015flenir.<\/p>\n\n
Bir Vaka Analizi: E-Ticaret Sadakat Puan\u0131 Batch \u0130\u015fi<\/h2>\n
HTTP 429<\/code> d\u00f6nmeye ba\u015flad\u0131. Ancak as\u0131l tehlike \u015fuydu: API Gateway HTTP 429<\/code> yan\u0131t\u0131n\u0131 istemciye iletmeden hemen \u00f6nce, arka plandaki i\u015f\u00e7i servis (worker service) veri taban\u0131 i\u015flemini \u00e7oktan tamamlam\u0131\u015ft\u0131. \u0130stemci 429 kodunu g\u00f6r\u00fcnce otomatik olarak retry mekanizmas\u0131n\u0131 tetikledi ve ayn\u0131 500 ki\u015filik paketi tekrar g\u00f6nderdi.<\/p>\n\n\n
\n \nMetrik \/ Durum<\/th>\n Beklenen De\u011fer<\/th>\n Ger\u00e7ekle\u015fen De\u011fer<\/th>\n Sonu\u00e7<\/th>\n<\/tr>\n<\/thead>\n \n \u0130\u015flenen Paket Say\u0131s\u0131<\/td>\n 20 Paket<\/td>\n 20 Paket<\/td>\n Ba\u015far\u0131l\u0131 gibi g\u00f6r\u00fcn\u00fcyor<\/td>\n<\/tr>\n \n Toplam \u0130stek Say\u0131s\u0131<\/td>\n 20 \u0130stek<\/td>\n 68 \u0130stek<\/td>\n 48 M\u00fckerrer Retry \u0130ste\u011fi<\/td>\n<\/tr>\n \n Da\u011f\u0131t\u0131lan Toplam Puan<\/td>\n 100.000 Puan<\/td>\n 240.000 Puan<\/td>\n %140 Fazla Puan Da\u011f\u0131t\u0131m\u0131<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n A\u011f \u0130leti\u015fiminde Yan\u0131lsama: \u0130stek Ba\u015far\u0131l\u0131 Ama Yan\u0131t Hatayla m\u0131 D\u00f6nd\u00fc?<\/h3>\n
COMMIT<\/code> edilmi\u015f olsa dahi, paket istemciye ula\u015fmad\u0131\u011f\u0131 i\u00e7in istemci uygulaman\u0131n durumunu FAILED<\/code> olarak i\u015faretler. Bu noktada korumas\u0131z bir d\u00f6ng\u00fc, veriyi tekrar basmaya ba\u015flayacakt\u0131r. Bu y\u00fczden \u00e7\u00f6z\u00fcm\u00fc sadece istemci taraf\u0131nda de\u011fil, sunucu ve istemci aras\u0131ndaki mimari s\u00f6zle\u015fmede (contract) aramam\u0131z gerekir.<\/p>\n\u00c7\u00f6z\u00fcm\u00fcn Kalbi: Idempotency (E\u015fg\u00fc\u00e7l\u00fcl\u00fck) Mimarisi<\/h2>\n
GET<\/code>, PUT<\/code> ve DELETE<\/code> do\u011fas\u0131 gere\u011fi idempotent kabul edilirken, POST<\/code> istekleri varsay\u0131lan olarak idempotent de\u011fildir.<\/p>\nPOST<\/code> isteklerini idempotent hale getirmek i\u00e7in Idempotency Key (E\u015fg\u00fc\u00e7l\u00fcl\u00fck Anahtar\u0131)<\/strong> desenini uygulad\u0131k. Bu y\u00f6ntemde istemci, g\u00f6nderdi\u011fi her batch paketi i\u00e7in benzersiz bir anahtar (\u00f6rne\u011fin bir UUID v4 veya paketteki verilerin karmas\u0131\/hash de\u011feri) \u00fcretir ve bunu HTTP ba\u015fl\u0131\u011f\u0131nda (header) sunucuya iletir.<\/p>\n\n
X-Idempotency-Key<\/code> de\u011feri okunur.<\/li>\nRetry Stratejilerini \u0130yile\u015ftirme: Exponential Backoff ve Jitter<\/h2>\n
HTTP 429<\/code> ald\u0131\u011f\u0131nda an\u0131nda ve s\u00fcrekli retry yapmaya devam ederse, hedef sunucunun toparlanmas\u0131na asla izin vermez. Bu duruma sistem mimarisinde “G\u00fcr\u00fclt\u00fcl\u00fc S\u00fcr\u00fc Problemi” (Thundering Herd Problem) ad\u0131 verilir.<\/p>\nBekleme S\u00fcresi = Min(Max_Bekleme, Taban_S\u00fcre * (2 ^ Deneme_Say\u0131s\u0131)) + Rastgele_Sapma<\/code><\/p>\nKod Uygulamas\u0131: \u0130dempotent Batch \u0130\u015fleyici \u00d6rne\u011fi<\/h3>\n
X-Idempotency-Key<\/code> ba\u015fl\u0131\u011f\u0131n\u0131 kullanan hem de \u00fcstel bekleme ve jitter algoritmas\u0131na sahip g\u00fcvenli bir batch HTTP istemcisi yer almaktad\u0131r. Kod bloklar\u0131m\u0131z temiz ve standart yap\u0131da kurgulanm\u0131\u015ft\u0131r.<\/p>\nimport axios, { AxiosError, AxiosResponse } from 'axios';\nimport { crypto } from 'crypto';\n\ninterface BatchPayload {\n batchId: string;\n items: Array<{ userId: string; points: number }>;\n}\n\nasync function sendBatchWithIdempotentRetry(\n payload: BatchPayload,\n maxRetries: number = 5\n): Promise<AxiosResponse> {\n const url = 'https:\/\/api.sirketiniz.com\/v1\/loyalty\/batch-points';\n \n \/\/ Determinastik veya benzersiz anahtar \u00fcretimi\n const idempotencyKey = payload.batchId || crypto.randomUUID();\n\n for (let attempt = 0; attempt < maxRetries; attempt++) {\n try {\n const response = await axios.post(url, payload, {\n headers: {\n 'Content-Type': 'application\/json',\n 'X-Idempotency-Key': idempotencyKey\n },\n timeout: 5000 \/\/ 5 saniye zaman a\u015f\u0131m\u0131\n });\n\n return response; \/\/ Ba\u015far\u0131l\u0131 ise sonucu d\u00f6n\n } catch (error) {\n const axiosError = error as AxiosError;\n const isRateLimited = axiosError.response?.status === 429;\n const isServerError = axiosError.response?.status && axiosError.response.status >= 500;\n \n \/\/ Son denemeyse veya retry yap\u0131lamaz bir hataysa hatay\u0131 f\u0131rlat\n if (attempt === maxRetries - 1 || (!isRateLimited && !isServerError)) {\n throw error;\n }\n\n \/\/ Exponential Backoff + Jitter Hesaplamas\u0131\n const baseDelay = 1000; \/\/ 1 saniye\n const exponentialDelay = baseDelay * Math.pow(2, attempt);\n const jitter = Math.random() * 1000; \/\/ 0-1000ms aras\u0131 rastgele sapma\n const totalDelay = Math.min(exponentialDelay + jitter, 30000); \/\/ Maksimum 30 sn\n\n console.warn(\u0130stek ba\u015far\u0131s\u0131z (${axiosError.response?.status}). ${totalDelay.toFixed(0)}ms sonra tekrar deneniyor... (Deneme: ${attempt + 1})<\/code>);\n \n await new Promise((resolve) => setTimeout(resolve, totalDelay));\n }\n }\n\n throw new Error('Maksimum retry s\u0131n\u0131r\u0131na ula\u015f\u0131ld\u0131.');\n}\n<\/code><\/pre>\n<\/div>\nX-Idempotency-Key<\/code> de\u011ferini g\u00f6nderir. Bu sayede sunucu 429 hatas\u0131 sonras\u0131 gelen m\u00fckerrer istekleri tespit edebilir.<\/p>\nDa\u011f\u0131t\u0131k Sistemlerde \u00c7ifte \u00c7al\u0131\u015fmay\u0131 \u00d6nleme: Redis Lock<\/h2>\n
SETNX<\/code> (Set if Not Exists) komutu bu t\u00fcr kilitleme i\u015flemleri i\u00e7in olduk\u00e7a uygundur.<\/p>\nimport Redis from 'ioredis';\nconst redis = new Redis();\n\nasync function processBatchServerSide(idempotencyKey: string, batchData: any) {\n const lockKey = lock:batch:${idempotencyKey}<\/code>;\n const resultKey = result:batch:${idempotencyKey}<\/code>;\n\n \/\/ 1. \u00d6nce daha \u00f6nce tamamlanm\u0131\u015f bir sonu\u00e7 var m\u0131 bak\n const cachedResult = await redis.get(resultKey);\n if (cachedResult) {\n return JSON.parse(cachedResult); \/\/ \u0130\u015flemi tekrar yapma, eski sonucu d\u00f6n!\n }\n\n \/\/ 2. \u0130\u015flem devam ediyor mu diye kilit (lock) almay\u0131 dene (30 saniye TTL)\n const acquiredLock = await redis.set(lockKey, 'PROCESSING', 'PX', 30000, 'NX');\n \n if (!acquiredLock) {\n \/\/ Kilit al\u0131namad\u0131, demek ki ba\u015fka bir worker \u015fu an bu batch'i i\u015fliyor\n throw new Error('Bu batch i\u015flemi \u015fu anda ba\u015fka bir sunucu taraf\u0131ndan i\u015fleniyor. L\u00fctfen bekleyin.');\n }\n\n try {\n \/\/ 3. Ger\u00e7ek Veri Taban\u0131 \u0130\u015flemleri (Business Logic)\n const dbResult = await executeDatabaseTransaction(batchData);\n\n \/\/ 4. Sonucu \u00f6nbelle\u011fe kaydet (\u00d6rn: 24 saat boyunca sakla)\n await redis.set(resultKey, JSON.stringify(dbResult), 'EX', 86400);\n\n return dbResult;\n } finally {\n \/\/ 5. \u0130\u015flem bitince kilidi kald\u0131r\n await redis.del(lockKey);\n }\n}\n<\/code><\/pre>\n<\/div>\nMimaride Sa\u011flanan Kazan\u0131mlar<\/h2>\n
\n
Sonu\u00e7 ve De\u011ferlendirme<\/h2>\n
HTTP 429 Too Many Requests<\/code> gibi oran s\u0131n\u0131rlama yan\u0131tlar\u0131 yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinin do\u011fal bir par\u00e7as\u0131d\u0131r. Ancak bu hatalara verilen tepkinin kontrols\u00fcz bir retry mekanizmas\u0131 olmas\u0131, hatan\u0131n etkisini katlayarak b\u00fcy\u00fctebilir.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h2>\n
1. HTTP 429 hatas\u0131 ald\u0131\u011f\u0131mda iste\u011fin sunucuda \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 nas\u0131l anlar\u0131m?<\/h3>\n
Idempotency-Key<\/code> eklemek ve sunucunun bu anahtara g\u00f6re i\u015flem yapmas\u0131n\u0131 sa\u011flamakt\u0131r.<\/p>\n2. Idempotency Key de\u011ferlerini ne kadar s\u00fcreyle depolamal\u0131y\u0131m?<\/h3>\n
3. Exponential Backoff kullan\u0131rken maksimum retry say\u0131s\u0131 ka\u00e7 olmal\u0131d\u0131r?<\/h3>\n
4. Jitter (Rastgele Sapma) eklemek neden bu kadar \u00f6nemlidir?<\/h3>\n