Redis के साथ हाई-परफॉर्मेंस रियल-टाइम ट्रेडिंग प्लेटफॉर्म डिजाइन करना

पोर्टफोलियो धन और संपत्ति प्रबंधन उद्योग की नींव बनाते हैं। हैरी माकविट्ज़ द्वारा आधुनिक पोर्टफोलियो सिद्धांत का नेतृत्व करने के बाद से, संपत्ति और धन प्रबंधन पेशेवर अपने पोर्टफोलियो पर दिए गए जोखिम स्तर के लिए रिटर्न को अधिकतम करने पर ध्यान केंद्रित करते रहे हैं। आज, उद्योग के पेशेवर लाखों खुदरा निवेशकों द्वारा जुड़ गए हैं, जिन्होंने निवेश के परिदृश्य को हमेशा के लिए बदल दिया है। ये नए प्रवेशकर्ता खुदरा ब्रोकरेज, एक्सचेंज, और क्लियरिंग हाउस के ट्रेडिंग इन्फ्रास्ट्रक्चर को रेखांकित करने वाली तकनीक के लिए भारी निहितार्थ पैदा कर रहे हैं।

उदाहरण के लिए, जनवरी 2021 के GameStop स्टॉक उन्माद को लें। खुदरा निवेशकों ने GameStop स्टॉक को रिकॉर्ड स्तर पर ट्रेड करना शुरू किया। इन निवेशकों ने AMC एंटरटेनमेंट जैसे अन्य मीम स्टॉक्स में भी ढेर किया, जिससे समग्र बाजार अस्थिरता VIX द्वारा मापे गए अनुसार कुछ ट्रेडिंग दिनों में 76% से अधिक बढ़ गई। इस अस्थिरता ने हजारों प्रतिभूतियों पर मूल्य दबाव डाला। लाखों निवेशक एक ही समय में अपने पोर्टफोलियो तक पहुंचने की बेताब कोशिश कर रहे थे, लेकिन ऐसे ऐप्स का सामना करना पड़ा जो मांग के साथ तालमेल नहीं रख सके। निवेशक उन कंपनियों के प्रति दयालु नहीं हैं जिनके ऐप्स सबसे ज्यादा जरूरत होने पर अच्छा प्रदर्शन नहीं करते।

इन उन्मादी समय के दौरान, अधिकांश निवेशक अपने पोर्टफोलियो के बारे में दो डेटा पॉइंट्स की तलाश कर रहे हैं जिनकी उन्हें हर समय पहुंच की आवश्यकता होती है:

1. उस समय पोर्टफोलियो का कुल मूल्य क्या है?
2. उनके पोर्टफोलियो में विशिष्ट प्रतिभूतियों के लाभ या हानि क्या हैं?

इन सवालों के जवाब एक निवेशक को विशिष्ट प्रतिभूतियों को खरीदने, बेचने, या रखने के लिए प्रेरित कर सकते हैं। आज के तेजी से बढ़ते बाजारों में, कोई भी देरी खोए हुए अवसर और मुनाफे का मतलब हो सकती है। इन सवालों का जवाब देने के लिए आपको कीमतों तक रीयल-टाइम पहुंच की आवश्यकता है—फिर भी दो बड़ी चुनौतियां हैं:

• हजारों प्रतिभूतियों की कीमतों को एक साथ अपडेट करना
• एक साथ लाखों ग्राहक अनुरोधों का जवाब देना।

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

अनिवार्य रूप से, हम एक रीयल-टाइम स्टॉक चार्ट बना रहे हैं। कई ब्रोकरेज ऐप्स इसे स्केल पर करने की कोशिश नहीं करते। इसके बजाय, ये ऐप्स लाखों क्लाइंट्स को कीमतों को पुश करने के बजाय नवीनतम कीमतों को खींचते हैं। उदाहरण के लिए, उनके पोर्टफोलियो पेज पर एक रिफ्रेश बटन हो सकता है।

ये अगली पीढ़ी की चुनौतियां तुच्छ नहीं हैं और डिस्क-आधारित डेटाबेस के साथ आसानी से हल नहीं की जा सकतीं, जिन्हें प्रति सेकंड लाखों ऑपरेशन को संभालने के लिए डिज़ाइन नहीं किया गया था। वित्तीय उद्योग की आवश्यकताओं को एक ऐसे डेटाबेस की आवश्यकता होती है जो आसानी से स्केल कर सके और प्रति सेकंड सैकड़ों मिलियन ऑपरेशन को संभाल सके। Redis Enterprise आता है, एक इन-मेमोरी डेटाबेस प्लेटफॉर्म, जिसमें इन असंख्य चुनौतियों से निपटने की क्षमता है।

यह वित्तीय दुनिया में विभिन्न रीयल-टाइम उपयोग के मामलों को कवर करने वाली ब्लॉग्स की एक श्रृंखला का पहला है। हम प्रत्येक उपयोग के मामले के विवरण और व्यावसायिक चुनौतियों और उन चुनौतियों को हल करने में Redis Enterprise की भूमिका को कवर करेंगे। ब्लॉग के हिस्से के रूप में, हम नमूना डिजाइन, डेटा मॉडल, और कोड सैंपल प्रदान करते हैं। हम प्रत्येक दृष्टिकोण के फायदे और नुकसान पर भी चर्चा करेंगे।

इस ब्लॉग पोस्ट में हम निम्नलिखित को कवर करेंगे:

• Redis Enterprise पर हाई-परफॉर्मेंस और स्केलेबल सिक्योरिटीज पोर्टफोलियो डेटा मॉडल का एक नमूना कार्यान्वयन।
• ब्रोकरेज द्वारा एक्सचेंजों से नवीनतम कीमतें प्राप्त होते ही पोर्टफोलियो में प्रतिभूतियों की कीमतों को रीयल-टाइम में अपडेट करना।

एक बार जब क्लाइंट ऐप ने पोर्टफोलियो प्राप्त कर लिया है और नवीनतम कीमतें प्राप्त कर रहा है, तो यह कर सकता है:

• पोर्टफोलियो के कुल मूल्य की गणना करें।
• प्रत्येक पोर्टफोलियो होल्डिंग पर लाभ या हानि की गणना करें।

सिक्योरिटीज पोर्टफोलियो डेटा मॉडल

आइए पोर्टफोलियो में होल्डिंग को मॉडल करके शुरू करें। नीचे दिए चित्रण में, CVS Health Corp. (NYSE: CVS) हमारी उदाहरण होल्डिंग्स में से एक है। CVS के दो अलग-अलग लॉट थे—पहला 4 जनवरी, 2021 को अधिग्रहित किया गया था और दूसरा 1 मार्च, 2021 को। प्रत्येक लॉट के लिए खरीद ट्रेड के दौरान समान संख्या में शेयर खरीदे गए थे। दोनों ट्रेड 10 शेयरों के लिए थे, हालांकि अलग-अलग प्रति शेयर कीमतों पर—पहले लॉट के लिए $68.3378 और दूसरे के लिए $68.82। पोर्टफोलियो में CVS होल्डिंग की कुल मात्रा 20 है जिसकी औसत लागत इस प्रकार गणना की गई है: (($68.3378 * 10) + ($68.82 * 10))/20 = $68.5789 प्रति शेयर।

आवश्यकताओं को लागू करना

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

यहां डेटा मॉडल निम्नलिखित एंटिटीज़ का उल्लेख करता है:

एक ER डायग्राम एक दृश्य प्रतिनिधित्व प्रदान करता है जो यह देखने में मदद कर सकता है कि क्या हो रहा है।

उपरोक्त डायग्राम से गायब है आने वाली कीमतों का सेट हालांकि वे सुरक्षा के मूल्य इतिहास में दर्ज हैं—और तात्कालिक मूल्य और लाभ की गणना जैसे ही कीमतें बदलती हैं। इसलिए, ER डायग्राम तुलनात्मक रूप से स्थिर डेटा का प्रतिनिधित्व करता है जो वह संदर्भ है जिसमें पोर्टफोलियो मूल्यांकन किया जाता है।

समग्र आर्किटेक्चर

इस प्रणाली के बारे में विचार करने योग्य मुख्य बिंदुओं में शामिल हैं:

• समयबद्धता (यानी लेटेंसी) महत्वपूर्ण है। यह समग्र ड्राइविंग संपत्ति है।
• पोर्टफोलियो मूल्य की गणना खाता-विशिष्ट डेटा (यानी लॉट जानकारी) को साझा डेटा (यानी सुरक्षा कीमतों) के साथ जोड़ती है। खाता-विशिष्ट डेटा इस प्रकार वह संदर्भ है जिसमें साझा डेटा उपयोग किया जाता है।
• पोर्टफोलियो मूल्य की गणना केवल उन खातों के लिए करने की आवश्यकता है जहां निवेशक ऑनलाइन है (कुल खातों का एक अंश)।
• डेटा एक्सचेंजों से होकर सिस्टम के माध्यम से बहता है जहां कीमतें उत्पन्न होती हैं, क्लाइंट मशीनों (ब्राउज़र, मोबाइल फोन एप्लिकेशन) तक जो ऑनलाइन निवेशकों को पोर्टफोलियो मूल्य प्रस्तुत करते हैं।
• विशेष रूप से उच्च गतिशीलता वाले क्षेत्रों में इनपुट डेटा फ्लो की दर और ऑनलाइन निवेशकों की संख्या शामिल है।

इन बिंदुओं को देखते हुए, कुछ सामान्य दृष्टिकोण हैं:

• स्थिर और गतिशील दोनों डेटा के लिए कम लेटेंसी एक्सेस के लिए Redis की इन-मेमोरी आर्किटेक्चर पर भरोसा करना।
• धीरे-धीरे बदलते प्रासंगिक डेटा तक तेजी से पहुंच प्रदान करने के लिए Redis की डेटा संरचनाओं का उपयोग करके डेटा मॉडलिंग को अनुकूलित करना।
• गतिशील डेटा आवश्यकताओं को संभालने के लिए Redis के संचार संरचनाओं (Streams, Consumer Groups, Pub/Sub) का उपयोग करना।
• समग्र सिस्टम प्रदर्शन को प्रभावित किए बिना केवल वही डेटा स्टोर करना जो आवश्यक है।
• क्लाइंट-विशिष्ट गणनाओं को स्वयं क्लाइंट्स पर लागू करना। यह ऑनलाइन निवेशकों की संख्या के साथ स्वाभाविक रूप से और स्वचालित रूप से स्केल करता है, जिससे स्केल का बोझ काफी कम हो जाता है।

यहां प्रमुख कम्प्यूटेशनल घटक और डेटा फ्लो हैं:

ध्यान दें कि Redis Enterprise में कई मशीनों पर एक या अधिक नोड्स होते हैं—ऑन-प्रिमाइसेस, Kubernetes, हाइब्रिड क्लाउड डिप्लॉयमेंट, प्रबंधित सेवा, या नेटिव फर्स्ट-पार्टी क्लाउड सेवा के रूप में तैनात—और सैकड़ों हजारों निवेशक अपनी पसंद के क्लाइंट्स के साथ ऑनलाइन होंगे।

Redis Enterprise घटक

सुरक्षा मूल्य अपडेट Redis Streams द्वारा अवशोषित किए जाएंगे। प्रतिभूतियों के लिए अपडेट इस स्ट्रीम में एक साथ मिश्रित होंगे और डेटा को उपयोगी बनाने के लिए विघटित करने की आवश्यकता होगी। उस विघटन को करने के लिए एक कंज्यूमर ग्रुप का उपयोग किया जाएगा, और प्रति सुरक्षा दो संरचनाओं में डेटा प्रोसेस करने के लिए:

• RedisTimeSeries डेटाबेस, मूल्य परिवर्तनों के इतिहास को ट्रैक करने के लिए (साथ ही किसी भी क्लाइंट के लिए सबसे नवीनतम मूल्य रिकॉर्ड करने के लिए जो अभी कनेक्ट हो रहा है)
• Pub/Sub ब्रोकर चैनल उन क्लाइंट्स को मूल्य परिवर्तन सूचनाएं पुश करने के लिए जिन्होंने उस चैनल की सदस्यता ली है (यानी निवेशक जिनके पोर्टफोलियो में वह सुरक्षा शामिल है)

निम्नलिखित डायग्राम इस आर्किटेक्चर के इस हिस्से को विस्तार से बताता है:

हमारे मॉडल में सबसे महत्वपूर्ण कारक लॉट्स और संबंधित सुरक्षा का प्रतिनिधित्व करने वाला खाता-विशिष्ट डेटा है। हम दो कार्यान्वयनों की तुलना करेंगे कि Redis में डेटा मॉडलिंग के बारे में कैसे सोचा जाए, प्रदर्शन पर ध्यान केंद्रित करते हुए। अन्य कार्यान्वयन संभव हैं—हमारा लक्ष्य यहां समग्र डिजाइन सिद्धांतों और विचार प्रक्रियाओं को पेश करना है जब Redis में डेटा लागू किया जाता है।

हम एक ठोस उदाहरण के रूप में निम्नलिखित जानकारी का उपयोग करेंगे:

हम सबसे कम संभव मुद्रा मूल्यवर्ग में मूल्य निर्धारण कर रहे हैं ताकि फ्लोट से बचा जा सके और सब कुछ पूर्णांकों में रखा जा सके। हम क्लाइंट को डॉलर और सेंट में परिवर्तन को संभालने की अनुमति दे सकते हैं। इस उदाहरण में, हम दो दशमलव स्थानों की सटीकता के साथ कीमतों का उपयोग कर रहे हैं।

डेटा मॉडल A

हमारा पहला कार्यान्वयन एक SET का उपयोग करके खाते में सभी लॉट्स की आईडी को रिकॉर्ड करता है, जिसे खाता आईडी द्वारा पहचाना जाता है, और फिर प्रति लॉट एक रेडिस HASH का उपयोग करता है, जिसे लॉट आईडी द्वारा पहचाना जाता है, जिसमें टिकर, मात्रा, और खरीद मूल्य फ़ील्ड के रूप में होते हैं। दूसरे शब्दों में, हम लॉट एंटिटी संरचना को मॉडल करने के लिए HASH का उपयोग कर रहे हैं, जिसमें लॉट एंटिटी का प्रत्येक गुण रेडिस HASH में एक फ़ील्ड होता है।

इस डेटा मॉडल के साथ हमारे पास प्रत्येक खाते के लिए एक कुंजी होती है और एक मान जिसमें उस खाते के सभी लॉट आईडी होते हैं जो रेडिस SET के रूप में संग्रहीत होते हैं:

इसके अलावा, प्रत्येक लॉटआईडी के लिए, हमारे पास एक HASH होगा जिसके फ़ील्ड टिकर, मात्रा, और खरीद मूल्य हैं:

ठोस रूप से, हम कुंजियों को इस तरह बनाएंगे:

127.0.0.1:6379> SADD lotids:ACC-1001 LOT-9001 LOT-9002 (integer) 2 127.0.0.1:6379> HMSET lot:LOT-9001 ticker AAPL quantity 200 price 12556 OK 127.0.0.1:6379> HMSET lot:LOT-9002 ticker CAT quantity 1200 price 18063 OK

RedisTimeSeries मॉड्यूल समय और मूल्यों के संबंधित जोड़े के भंडारण और पुनर्प्राप्ति की अनुमति देता है, साथ ही हाई-वॉल्यूम इन्सर्ट्स और लो-लेटेंसी रीड्स। हम क्लाइंट द्वारा संबंधित टाइम सीरीज कुंजियों का उपयोग करके रुचि के टिकर्स के लिए नवीनतम मूल्य प्राप्त करने जा रहे हैं:

127.0.0.1:6379> TS.GET price_history:APPL 1) (integer) 1619456853061 2) 12572 127.0.0.1:6379> TS.GET price_history:CAT 1) (integer) 1619456854120 2) 18021

और अपडेट के लिए मूल्य चैनल की सदस्यता लें:

सभी डेटा प्राप्त करने के लिए, क्लाइंट निम्नलिखित ऑपरेशन करेगा:

1. 1 बार lotids कुंजी पर SMEMBERS—समय जटिलता O(N) जहां N लॉट्स की संख्या है
2. N बार lot कुंजियों पर HGETALL—समय जटिलता N बार O(1)
3. T बार price_history कुंजियों पर TS.GET – समय जटिलता T बार O(1) जहां T टिकर्स की संख्या है
4. 1 बार <TICKER> चैनलों पर SUBSCRIBE – समय जटिलता O(T) (एक ही SUBSCRIBE कॉल में सभी चैनलों की सदस्यता ले सकते हैं)

कुल समय जटिलता O(N +T) है।

ठोस रूप से, ऑपरेशन एक और दो होंगे:

127.0.0.1:6379> SMEMBERS lotids:ACC1001 1) "LOT-9001" 2) "LOT-9002" 127.0.0.1:6379> HGETALL lot:LOT-9001 1) "ticker" 2) "AAPL" 3) "quantity" 4) "200" 5) "price" 6) "12556" 127.0.0.1:6379> HGETALL lot:LOT-9002 1) "ticker" 2) "CAT" 3) "quantity" 4) "1200" 5) "price" 6) "18063" 

हम पाइपलाइनिंग (क्लाइंट-साइड पर बैचिंग का एक रूप) और/या LUA स्क्रिप्ट्स के बार-बार उपयोग (SCRIPT LOAD & EVALSHA का उपयोग करके) द्वारा नेटवर्क लेटेंसी को कम कर सकते हैं। साइड नोट: ट्रांजैक्शन्स को पाइपलाइन्स का उपयोग करके लागू किया जा सकता है और कम नेटवर्क लेटेंसी प्रदान कर सकते हैं, लेकिन यह क्लाइंट-विशिष्ट है और उनका लक्ष्य सर्वर पर परमाणुता है, इसलिए वे वास्तव में नेटवर्क लेटेंसी समस्या को हल नहीं करते। पाइपलाइन्स उन कमांड्स से बने होते हैं जिनके इनपुट और आउटपुट एक दूसरे से स्वतंत्र होने चाहिए। LUA स्क्रिप्ट्स के लिए सभी कुंजियों को अग्रिम में प्रदान करना आवश्यक है और सभी कुंजियों को एक ही स्लॉट पर हैश किया जाना चाहिए (इस विषय पर अधिक जानकारी के लिए Redis Enterprise डॉक्स देखें)।

इन प्रतिबंधों को देखते हुए हम देख सकते हैं कि ऑपरेशन्स का पाइपलाइन्स को असाइनमेंट है:

• पाइपलाइन 1: ऑपरेशन #1 का एकल कमांड
• पाइपलाइन 2: ऑपरेशन #2 के सभी N कमांड्स
• पाइपलाइन 3: ऑपरेशन #3 और #4 के सभी N कमांड्स

और LUA स्क्रिप्ट्स का उपयोग करना संभव नहीं है क्योंकि प्रत्येक ऑपरेशन अलग-अलग कुंजियों का उपयोग करता है और उन कुंजियों का कोई सामान्य हिस्सा नहीं है जिसे एक ही स्लॉट पर हैश किया जा सके।

इस मॉडल का उपयोग करने पर हमारे पास O(N+T) की समय जटिलता और तीन नेटवर्क हॉप्स हैं।

डेटा मॉडल B

एक वैकल्पिक मॉडल लॉट एंटिटी संरचना को फ्लैट करना है और खाता आईडी द्वारा पहचाने जाने वाले एक कुंजी का उपयोग करके प्रत्येक एंटिटी गुण को दर्शाना है—लॉट के प्रत्येक गुण (मात्रा, टिकर, मूल्य) के लिए एक ऐसी कुंजी। प्रत्येक HASH में फ़ील्ड लॉट आईडी और मात्रा, टिकर, या मूल्य के अनुरूप एक मान होगा। इस प्रकार हमारे पास कुंजियाँ होंगी:

tickers_by_lot: <ACCOUNT_ID> HASH <LOTID TICKER>

quantities_by_lot:<ACCOUNT_ID> HASH <LOTID INTEGER>

prices_by_lot:<ACCOUNT_ID> HASH <LOTID INTEGER>

ये हैश डेटा मॉडल A से LOTID और LOT कुंजियों को प्रतिस्थापित करेंगे, जबकि price_history और <TICKER> कुंजियाँ समान रहेंगी।

कुंजियाँ बनाना:

HSET tickers_by_lot:ACC-1001 LOT-9001 AAPL LOT-9002 CAT HSET quantities_by_lot:ACC-1001 LOT-9001 200 LOT-9002 1200 HSET prices_by_lot:ACC-1001 LOT-9001 125.56 LOT-9002 180.63 

मान पुनर्प्राप्त करना:

127.0.0.1:6379> HGETALL tickers_by_lot:ACC-1001 1) "LOT-9001" 2) "AAPL" 3) "LOT-9002" 4) "CAT" 127.0.0.1:6379> HGETALL quantities_by_lot:ACC-1001 1) "LOT-9001" 2) "200" 3) "LOT-9002" 4) "1200" 127.0.0.1:6379> HGETALL prices_by_lot:ACC-1001 1) "LOT-9001" 2) "12556" 3) "LOT-9002" 4) "18063" 

क्लाइंट द्वारा आवश्यक ऑपरेशन अब होंगे:

1. 1 बार lot_quantity कुंजियों पर HGETALL—समय जटिलता N x O(1)
2. 1 बार lot_ticker कुंजियों पर HGETALL—समय जटिलता N x O(1)
3. 1 बार lot_price कुंजियों पर HGETALL—समय जटिलता N x O(1)
4. T बार price_history कुंजियों पर TS.GET—समय जटिलता T x O(1) जहां T टिकर्स की संख्या है
5. 1 बार <TICKER> चैनलों पर SUBSCRIBE—समय जटिलता 1 x O(T)

इसकी कुल समय जटिलता O(N+T) है—पहले जैसी ही।

पाइपलाइन के दृष्टिकोण से यह बन जाता है:

• पाइपलाइन एक—ऑपरेशन #1, #2, और #3 के सभी कमांड्स
• पाइपलाइन दो—ऑपरेशन #4 और #5 के सभी T कमांड्स

तो हमने नेटवर्क हॉप्स को एक से कम कर दिया है—पूर्ण रूप से बहुत नहीं, लेकिन सापेक्ष रूप से 33%।

इसके अलावा, हम आसानी से LUA का उपयोग कर सकते हैं क्योंकि हम कुंजियों को जानते हैं, और हम किसी विशिष्ट खाते के लिए सभी कुंजियों को एक ही स्लॉट पर मैप कर सकते हैं। ऑपरेशन की सादगी को देखते हुए हम LUA में गहराई से नहीं जाएंगे, लेकिन ध्यान दें कि यह डिजाइन इसे कम से कम संभव बनाता है!

एक साधारण बेंचमार्क में, डेटा मॉडल B 4.13 ms तेज चला (हजारों रन पर बेंचमार्क किया गया)। चूंकि यह केवल हर बार एक खाते के लिए क्लाइंट इनिशियलाइज़ होने पर चलता है, इसलिए इसका समग्र प्रदर्शन पर कोई प्रभाव नहीं पड़ने की संभावना है।

सारांश

इस ब्लॉग में, हमने Redis डेटा प्रकारों का उपयोग करके एंटिटी मॉडल के दो संभावित कार्यान्वयन दिखाए हैं। हमने समय जटिलता विश्लेषण भी पेश किया है जिसे Redis डेटा प्रकार चुनते समय किया जाना चाहिए, साथ ही नेटवर्क प्रदर्शन सुधारों पर विचार—एक महत्वपूर्ण कदम जब बड़े पैमाने और उच्च प्रदर्शन की आवश्यकता होती है। बाद के ब्लॉग्स में, हम इन विचारों पर आगे विस्तार करेंगे क्योंकि डेटा मॉडल का विस्तार होता है।

हमने बड़े पैमाने पर सिक्योरिटीज पोर्टफोलियो प्रबंधन में कुछ व्यावसायिक चुनौतियों को पेश किया है और निम्नलिखित दिखाया है:

• रियल-टाइम और स्केलेबल सिक्योरिटीज पोर्टफोलियो को लागू करने के लिए एक Redis डेटा मॉडल।
• एक हाई-परफॉर्मेंस, रीयल-टाइम मूल्य अपडेट सिस्टम जिसका उपयोग पोर्टफोलियो के कुल मूल्य और प्रत्येक होल्डिंग के लाभ या हानि की गणना के लिए किया जा सकता है।

इन दो महत्वपूर्ण विशेषताओं के साथ, एक ब्रोकरेज ऐप क्लाइंट रीयल-टाइम पोर्टफोलियो अपडेट प्रदान कर सकता है जो लाखों खातों को संभालने के लिए प्रदर्शन और स्केल करता है। यह डिजाइन पोर्टफोलियो के कुल मूल्य और प्रत्येक होल्डिंग में लाभ या हानि को रीयल-टाइम में प्रस्तुत कर सकता है। यह डेटा मॉडल और आर्किटेक्चर सिक्योरिटीज से परे उपयोग के मामलों पर भी लागू किया जा सकता है जैसे क्रिप्टो, विज्ञापन एक्सचेंज, आदि।