Adaptive Routing
256 Blocks कैसे बुद्धिमान provider routing के माध्यम से विश्वसनीय ब्लॉकचेन access सुनिश्चित करता है
256 Blocks विश्वसनीयता और प्रदर्शन को अधिकतम करने के लिए स्वचालित रूप से कई RPC providers के बीच आपके requests को route करता है। यह पृष्ठ बताता है कि adaptive routing कैसे काम करती है और जब providers विफल होते हैं तो क्या होता है।
यह कैसे काम करता है
एक नज़र में, यहाँ बताया गया है कि जब हमारे endpoints पर एक request आती है तो क्या होता है:
- हम latency के आधार पर निकटतम region (Europe, US, Singapore, या South America) में आपके request को route करने के लिए DNS level routing का उपयोग करते हैं
- हम अपने policy engine के विरुद्ध आपके request का मूल्यांकन करते हैं
- हम weighted scoring का उपयोग करके एक provider का चयन करते हैं - उच्च-स्कोरिंग providers को चुने जाने की अधिक संभावना होती है
- अंत में, हम request को execute करते हैं, यदि provider विफल होता है तो स्वचालित failover के साथ
यह प्रत्येक request पर पारदर्शी रूप से होता है, चाहे यह एक RPC call हो या हमारे MCP integrations का उपयोग करते हुए एक agentic workflow हो।
Provider Scoring
प्रत्येक provider को दो कारकों के आधार पर स्कोर किया जाता है:
| कारक | प्रभाव |
|---|---|
| Success rate | विफल requests एक provider के score को भारी रूप से दंडित करती हैं |
| Latency | धीमी प्रतिक्रियाएं score को कम करती हैं, इसलिए degrading providers स्वाभाविक रूप से कम traffic प्राप्त करते हैं |
Scores region, chain, और provider के अनुसार गणना की जाती हैं। एक provider Europe में अच्छा प्रदर्शन कर सकता है लेकिन Singapore में खराब, या Ethereum को विश्वसनीय रूप से handle कर सकता है लेकिन Polygon के साथ संघर्ष कर सकता है।
Scores प्रत्येक request पूरी होने के कुछ सेकंड के भीतर अपडेट हो जाते हैं। बाद की requests तुरंत नवीनतम प्रदर्शन डेटा से लाभान्वित होती हैं।
Degraded providers
जब किसी provider का score एक threshold से नीचे गिर जाता है, तो इसे अस्थायी रूप से उपलब्ध pool से हटा दिया जाता है। यह requests को ऐसे provider पर route होने से रोकता है जो विफल होने की संभावना रखता है।
Scores समय के साथ धीरे-धीरे recover होते हैं, जिससे providers धीरे-धीरे pool में फिर से प्रवेश कर सकें। यह एक recovering provider को पूरी तरह से stable होने से पहले traffic से overwhelmed होने से रोकता है।
Automatic Failover
256 Blocks केवल तभी requests को retry करता है जब provider की प्रतिक्रिया यह संकेत देती है कि ऐसा करना सुरक्षित है:
| प्रतिक्रिया | क्रिया |
|---|---|
| 2xx | सफलता, response वापस करें |
| 401 (Unauthorized) | अगले provider के साथ Retry करें (transient auth issue) |
| 403 (Forbidden) | अगले provider के साथ Retry करें (transient issue) |
| 429 (Rate Limited) | अगले provider के साथ Retry करें |
| 5xx (Server Error) | अगले provider के साथ Retry करें |
| Other 4xx (Client Error) | Retry न करें - request स्वयं संभवतः अमान्य है |
| Timeout | Retry न करें (double-charging से बचें) |
| Connection Error | अगले provider के साथ Retry करें (request provider तक कभी नहीं पहुंची) |
जब failover होता है, तो प्रत्येक उपलब्ध provider को score order में तब तक try किया जाता है जब तक कि एक सफल न हो जाए या सभी providers को try न कर लिया जाए।