Skip to main content
A
// केस फ़ाइल 01 / 19
← सभी केस फ़ाइलें

Aero

क्लाइंटप्रोडक्शन में लाइव · 4 ऐप · AWSFastAPIFlutterPostgreSQLRedisAWS लाइव साइट देखें ↗
01> यह कैसे शिप हुआ
// चुनौती01

शहर-स्तर का राइड-हेलिंग प्लेटफ़ॉर्म सवारियाँ, ड्राइवर और भुगतान एक ऐसे बैकएंड पर ढो रहा था जो गिरता तो पूरा गिरता था — एक अटका हुआ इवेंट लूप हेल्थ चेक, डिस्पैच और बुकिंग तीनों को साथ ले डूबता था, और जिन रिपोर्टों की सबको ज़रूरत थी वे उन्हीं लाइव टेबलों से पूछती थीं जिनसे यात्री।

// दृष्टिकोण02

कोर को दो वर्कर वाली FastAPI सेवा के रूप में दोबारा बनाया: हर गर्म Redis रास्ते पर सर्किट ब्रेकर, क्लस्टर-सुरक्षित क़तारें और उनके पीछे फ़ॉलबैक क़तार, और रिपोर्टिंग को लाइव टेबलों से हटाकर तय समय पर ताज़ा होने वाले मटीरियलाइज़्ड व्यू पर — दिन का राजस्व, प्रदाता का प्रदर्शन, शहर की घंटे-दर-घंटे माँग।

// परिणाम03

कस्टमर ऐप, प्रोवाइडर ऐप, वेंडर कंसोल और वेब — चारों AWS पर एक ही मज़बूत कोर के सामने प्रोडक्शन में चलते हैं। अटकी हुई निर्भरता अब पूरे प्लेटफ़ॉर्म को नहीं, एक रास्ते को धीमा करती है, और पिछले महीने की माँग का सवाल टाला नहीं जाता, सेकंडों में जवाब पाता है।

case --info aero-platform
> क्लाइंट · Aero
> क्षेत्र · मोबिलिटी
> स्टैक · FastAPI · Flutter · PostgreSQL · Redis · AWS
> परिणाम · प्रोडक्शन में लाइव · 4 ऐप · AWS
> case/aero-platformशिप हुआ ▮

ऐसा ही सिस्टम चाहिए?

बताइए आप क्या बना रहे हैं। हम सेल्स पिच नहीं, एक स्कोप्ड प्लान भेजेंगे।