डेटाबेस किसी ऐप का वह हिस्सा होता है जो डेटा को स्टोर करता है, ताकि ऐप के रीस्टार्ट होने, सर्वर के क्रैश होने या बिजली चले जाने के बाद भी वह डेटा बना रहे। बाद में ऐप उस डेटा को खास तरीकों से मांग सकता है, जैसे ID के ज़रिए कोई एक रिकॉर्ड या यूज़र के हिसाब से फ़िल्टर की गई लिस्ट।
“डेटा” को बेहतर ढंग से समझने के लिए, एक छोटे से टास्क लिस्ट प्रोडक्ट का उदाहरण लेते हैं। हर टास्क एक रिकॉर्ड होता है जिसमें task_id, user_id, title, completed, और created_at जैसे फ़ील्ड होते हैं, और ऐप को दो बुनियादी कामों की ज़रूरत होती है। एक काम से टास्क बनता है, और दूसरे से यूज़र के टास्क की लिस्ट दिखती है।
सिंगल-सर्वर सेटअप में, क्लाइंट ऐप सर्वर को HTTP रिक्वेस्ट भेजता है, और ऐप सर्वर एक ही डेटाबेस में रो (rows) को पढ़ता और लिखता है। डेटाबेस “हर रिक्वेस्ट पर एक टास्क रो लिखी जाएगी” जैसे नियम लागू करके सही डेटा सुनिश्चित करता है, और इससे लेटेंसी (देरी) भी होती है क्योंकि डिस्क और मेमोरी में पढ़ने और लिखने में समय लगता है। आइए, एक बॉक्स डायग्राम पर इन दो रिक्वेस्ट पाथ (रास्तों) को देखते हैं।
‘create-task’ (टास्क बनाने) के अनुरोध पर, ऐप सर्वर इनपुट को वैलिडेट करता है, फिर डेटाबेस से एक नई टास्क रो (row) डालने के लिए कहता है, और आखिर में क्लाइंट को नया task_id भेजता है। क्लाइंट को डेटा के सुरक्षित रूप से सेव (durable) होने का पता तभी चलता है जब डेटाबेस इसकी पुष्टि कर देता है; इसीलिए सही काम करने के लिए डेटाबेस एक अहम भूमिका निभाता है।
‘list-tasks’ (टास्क की लिस्ट देखने) के अनुरोध पर, ऐप सर्वर डेटाबेस से उन सभी टास्क की जानकारी मांगता है जिनका user_id मैच करता है (अक्सर इन्हें created_at के आधार पर क्रम में लगाया जाता है), और फिर ऐप सर्वर रिस्पॉन्स को सही फ़ॉर्मैट में तैयार करता है। जब क्वेरी को ज़रूरत से ज़्यादा रो (rows) स्कैन करनी पड़ती हैं, तो डेटाबेस को ज़्यादा काम करना पड़ता है और क्लाइंट को ज़्यादा इंतज़ार करना पड़ता है; इसलिए परफ़ॉर्मेंस इस बात पर निर्भर करने लगती है कि डेटाबेस मैचिंग रो (rows) को कैसे ढूंढता है।
जैसे-जैसे ज़्यादा यूज़र टास्क जोड़ते हैं, सबसे पहले दिखने वाली समस्या आमतौर पर यह होती है कि ‘list-tasks’ धीमा हो जाता है, क्योंकि एक क्वेरी का जवाब देने के लिए डेटाबेस को बहुत ज़्यादा डेटा पढ़ना पड़ता है। इसके बाद, कोई ‘हॉट यूज़र’ (बहुत ज़्यादा एक्टिव यूज़र) या ‘शेयर्ड लिस्ट’ ऐसी स्थिति पैदा कर सकती है जहाँ कई ‘राइट’ ऑपरेशन (डेटा अपडेट करने की कोशिश) एक ही रो या रो के सेट को अपडेट करने की कोशिश करते हैं; इससे अनुरोध एक साथ (पैरेलल) पूरे होने के बजाय एक-दूसरे के पीछे कतार में लग जाते हैं। आखिर में, अगर सिंगल डेटाबेस प्रोसेस या मशीन बंद हो जाती है, तो पूरा ऐप काम करना बंद कर देता है क्योंकि हर अनुरोध उसी पर निर्भर करता है। अगला डायग्राम उन्हीं तीन प्रेशर पॉइंट्स को एक ही बेसलाइन पर दिखाता है।