एक CTO कैसे धीमी Queries ढूंढता है और Finance के एस्केलेट होने से पहले उन्हें ठीक करता है

NeonEdge एक Crypto-native iGaming Platform है जो Tallinn, Estonia में स्थित है। यह Platform ETH, Tron, Polygon और SOL पर Multi-chain Support के साथ Provably Fair Crash Games पर आधारित है। Platform लगभग पंद्रह हज़ार Monthly Active Users को सेवा देता है और प्रति सप्ताह लगभग $5M का Gross Gaming Revenue उत्पन्न करता है। यह एक Lean और तकनीकी रूप से महत्वाकांक्षी संगठन है — दो Engineers पूरे Data Infrastructure को संभालते हैं — और Priya Desai, CTO तथा Head of Data, वही व्यक्ति हैं जिन्हें Product और Finance दोनों तब Call करते हैं जब कुछ भी अपेक्षा से धीमा चलता है।

Products used: Query Performance Analytics, Infrastructure Monitor, Cost Optimization

20 मिनट | पूरी जांच का समय

3 | एक Cold Start से पहचानी गई समस्याग्रस्त Queries

12x | Optimizations Deploy होने के बाद औसत Speedup

---

चुनौती

शिकायतें अड़तालीस घंटों के भीतर, दो अलग-अलग दिशाओं से आईं। Product Team ने एक Slack Thread Filed की जिसमें कहा गया कि Player Activity Reports धीमी लग रही हैं — "कभी-कभी आप Click करते हैं और इंतजार करते हैं, फिर हार मान लेते हैं।" Finance और भी सीधी थी: साप्ताहिक GGR Reconciliation Report लोड होते-होते Timeout होने लगी थी और CFO ने क्रैश होने से पहले एक Half-rendered Page का Screenshot लेना शुरू कर दिया था। कोई Error Codes नहीं, कोई स्पष्ट विफलता नहीं — बस ऐसी धीमापन जो चुपके से परेशान करने से टूटने की स्थिति तक पहुँच गई थी।

इस तरह की समस्या के लिए Priya का Standard Diagnostic Toolkit तेज़ नहीं था। Multi-chain Data Stack में Query Latency को Trace करने के लिए तीन अलग-अलग Services के Logs को Correlate करना, Cluster Resource Utilization को Manually Check करना, और यह पुनर्निर्माण करना पड़ता था कि कौन सा Upstream Transformation किस Downstream Report में समय जोड़ रहा था। एक अच्छे दिन पर सही Logs के साथ इसमें दो से तीन घंटे लगते थे। बुरे दिन पर — जब Slow Query केवल Load के तहत दिखती है — यह पूरी दोपहर तक खिंच सकती थी।

ढाँचागत समस्या यह थी कि NeonEdge का Data Stack Organically बड़ा हुआ था। शुरुआती Engineering निर्णय — पाँच हज़ार MAU पर उचित — की समीक्षा तब नहीं हुई जब Platform पंद्रह हज़ार तक पहुँचा। किसी ने जानबूझकर Indexes छोड़ने या किसी Core Report में Table Scan लिखने का फैसला नहीं किया था; यह बस धीरे-धीरे हुआ, जब Team Features Ship करने पर ध्यान केंद्रित थी, Data Access Patterns का Audit करने के बजाय।

"हम दो लोगों की Data Team हैं जो पंद्रह हज़ार Users और पाँच मिलियन प्रति सप्ताह GGR के लिए Infrastructure चलाते हैं। मैं एक धीमी Query ढूंढने में पूरा दिन बर्बाद करने का Luxury नहीं कर सकती। मुझे बीस मिनट में Bottleneck स्क्रीन पर चाहिए, नहीं तो समस्या अगले Sprint तक बैठी रहती है।"

— Priya Desai, CTO, NeonEdge

---

समाधान

Priya ने Gaming Mind AI खोला और सादे शब्दों में लक्षण बताया: Reports सभी जगह से धीमी हैं, किसी को नहीं पता कौन सी Query दोषी है, और समस्या दो दिनों से बढ़ रही है। Gaming Mind NeonEdge के Infrastructure Telemetry से जुड़ा और सबसे सीधे Diagnostic प्रश्न से शुरुआत की — अभी Stack में कौन सी Queries सबसे अधिक Execution Time खा रही हैं।

यहाँ बताया गया है कि जांच कैसे आगे बढ़ी:

---

Priya: "Reports सभी जगह से धीमी हैं। मुझे पहले कहाँ देखना चाहिए?"

Rank	Query Name	Avg Execution Time	p99 Time	Runs/Day	Caller	% of Total Query Time
1	GGR Reconciliation Report	41.2 sec	68.4 sec	4	Finance	24%
2	Player Activity Report	31.0 sec	54.1 sec	8	Product	22%
3	Player Cohort Report	28.3 sec	47.6 sec	6	Product / CRM	12%
4	Affiliate Revenue Attribution	5.8 sec	11.2 sec	12	Marketing	4%
5	Daily Active User Summary	5.1 sec	9.7 sec	24	Ops	4%
6	Chain Settlement Reconciliation	4.9 sec	9.1 sec	6	Finance	3%
7	Churn Risk Score Refresh	4.4 sec	8.3 sec	2	CRM	2%
8	Wallet Balance Snapshot	3.8 sec	7.2 sec	48	Ops	2%
9	Bonus Utilisation Report	3.2 sec	6.4 sec	4	Product	1%
10	New Registrations Funnel	2.9 sec	5.8 sec	24	Marketing	1%
(अन्य सभी)	—	< 2.0 sec	< 4.0 sec	—	Various	25%
Top 3 कुल		~100 sec combined				58%
Top 10 कुल						71%

⚠️ Gaming Mind flags: Top 3 Queries कुल Query Execution Time का 58% हिस्सा लेती हैं। वितरण आश्चर्यजनक रूप से असमान है — Queries 1–3 औसतन 28–41 सेकंड प्रत्येक, जबकि Queries 4–10 मिलाकर 6 सेकंड से कम। Top 3 को ठीक करने से बिना कुछ और छुए कुल Query Time में अनुमानित 58% की कमी आएगी।

Gaming Mind की पहली प्रतिक्रिया पिछले सात दिनों की Query Execution का एक Ranked Latency Leaderboard था। Top दस सबसे धीमी Queries कुल Query Execution Time का 71% हिस्सा लेती थीं, लेकिन वितरण आश्चर्यजनक रूप से असमान था — तीन सबसे बुरे अपराधियों का औसत 28 से 41 सेकंड प्रत्येक था, जबकि चार से दस नंबर का औसत मिलाकर छह सेकंड से कम था। Gaming Mind ने Top तीन को तुरंत जांच के लायक एकमात्र Queries के रूप में Flag किया: उन्हें ठीक करने से बिना कुछ और छुए कुल Query Time में अनुमानित 58% की कमी आएगी। Priya को नब्बे सेकंड से कम में अपना शुरुआती बिंदु मिल गया।

---

Priya: "सबसे धीमी वाली के बारे में मुझे बताओ।"

Query: GGR Reconciliation Report

Stage	Operation	Rows Scanned	Rows Output	Stage Time	Cumulative Time
1	Full table scan — transaction_ledger	84,200,000	84,200,000	28.4 sec	28.4 sec
2	Filter: इस सप्ताह के Records	84,200,000	312,400	6.1 sec	34.5 sec
3	Join: chain metadata	312,400	312,400	2.8 sec	37.3 sec
4	Aggregate: GGR by chain + game type	312,400	48	1.9 sec	39.2 sec
5	Output Format करें	48	48	2.0 sec	41.2 sec

Diagnostic	Detail
Scanned Data Date Range	Platform Launch (18 महीने) से अब तक
Required Date Range	केवल वर्तमान सप्ताह
Scan से पहले Date Filter लागू	नहीं
Access Pattern Classification	Unfiltered Historical Scan
Severity	🔴 High — Append-heavy Ledger Architectures में ज्ञात Performance Antipattern
Root Cause	Scan से पहले WHERE Date Predicate नहीं — 18 महीने पुराना Design निर्णय जिसकी कभी समीक्षा नहीं हुई

⚠️ Gaming Mind flags: GGR Reconciliation Report — वही Query जिसके बारे में Finance ने शिकायत की — 18 महीनों के Transaction History में Full Table Scan कर रही है, जबकि प्रश्न का उत्तर केवल वर्तमान सप्ताह से देना है। Scan से पहले Date Filter लगाना ही एकमात्र आवश्यक Fix है। यही Finance CFO Timeout का Root Cause है।

सबसे बुरी Query वो GGR Reconciliation Report थी — बिल्कुल वही जिसके बारे में Finance ने शिकायत की थी। Gaming Mind ने इसका Execution Plan Stage-by-stage तोड़कर दिखाया: एक Full Table Scan Transaction Ledger की हर Row को छू रही थी, जिसमें Platform Launch से ऐतिहासिक Records भी शामिल थे, हर बार जब Report चलती। Query में Scan से पहले कोई Date Filter नहीं था, यानी यह केवल वर्तमान सप्ताह का उत्तर देने के लिए लगभग अठारह महीनों के Transaction History को Process कर रही थी। Gaming Mind ने इसे High-severity Access Pattern के रूप में Classify किया और इसे Unfiltered Historical Scan — Append-heavy Ledger Architectures में एक ज्ञात Performance Antipattern — के रूप में Label किया। Root Cause अठारह महीने पुराना एक Design निर्णय था जिसकी किसी ने समीक्षा नहीं की थी।

---

Priya: "दूसरी वाली के साथ क्या हो रहा है?"

Query: Player Activity Report

Stage	Operation	Input Rows	Output Rows	Stage Time	Cumulative Time
1	Scan: player_sessions	2,100,000	2,100,000	4.2 sec	4.2 sec
2	Join: game_events (filter से पहले wide)	2,100,000	18,700,000	12.8 sec	17.0 sec
3	Join: wallet_activity	18,700,000	18,700,000	7.1 sec	24.1 sec
4	Filter: player segment + date range	18,700,000	480,000	4.6 sec	28.7 sec
5	Aggregate + format	480,000	920	2.3 sec	31.0 sec

Diagnostic	Detail
Bottleneck Stage	Stage 2 — Join Filter संकुचित होने से पहले Expand होता है
Intermediate Result Set Peak	18,700,000 rows (~3x आवश्यक आकार)
कारण	Join Order सबसे संकीर्ण Filter से पहले Broad Join रखता है
Fix	game_events के साथ Join से पहले Player Segment + Date Filter लगाएं
Estimated Post-fix Intermediate Size	~6,200,000 rows
Estimated Post-fix Execution Time	< 5 sec
Memory Reduction	~66%

⚠️ Gaming Mind flags: Player Activity Report का Join Filter होने से पहले Expand हो रहा है — जो आवश्यक से लगभग 3x बड़ा Intermediate Result Set बना रहा है। Join Sequence में दो Steps को Reverse करने (पहले सबसे संकीर्ण Filter लगाने) से Intermediate Memory Consumption लगभग दो-तिहाई कम हो जाएगी और Execution Time 31 सेकंड से 5 से कम हो जाएगी।

दूसरी समस्याग्रस्त Query वो Player Activity Report Feed करती थी जिसे Product Team ने Flag किया था। Gaming Mind ने एक Multi-stage Join Identified किया जो Filter होने से पहले Expand हो रहा था — Peak Size पर एक Wide Intermediate Result Set Process कर रहा था, फिर उसे Player Segment और Date Range से Narrow कर रहा था। Join Order लगभग तीन गुना बड़े Intermediate Tables बना रहा था। Gaming Mind ने ठीक वह Stage Annotate किया जहाँ Result Set फूल गया था, और Estimated किया कि Join Sequence में दो Steps को Reverse करने — पहले सबसे संकीर्ण Filter लगाने — से Intermediate Memory Consumption लगभग दो-तिहाई कम होगी और Execution Time इकतीस सेकंड से पाँच से कम हो जाएगी।

---

Priya: "तीसरी वाली?"

Query: Player Cohort Report

Column	Individual Index Exists	Composite Index का हिस्सा	Cardinality	Intersection Resolve करने में समय
chain_identifier	Yes	No	Low (4 values)	—
registration_date	Yes	No	High (540 days)	—
game_category	Yes	No	Medium (12 values)	—
chain_identifier + registration_date + game_category	No	No	—	~19 sec प्रति Execution

Diagnostic	Detail
Missing Index Type	(chain_identifier, registration_date, game_category) पर Composite Index
Current Resolution Method	Query Time पर Manual Intersection
Composite Index के साथ Estimated Execution Time	< 3 sec
Platform पर इस Column Combination का उपयोग	14 distinct Queries
1 Composite Index जोड़ने से और Queries Accelerated	13
Severity	🔴 High — Single Fix, Platform-wide Impact

⚠️ Gaming Mind flags: इस Query के हर Version में दिखने वाले तीन Columns — chain_identifier, registration_date, और game_category — प्रत्येक अलग-अलग Indexed हैं लेकिन कभी Composite के रूप में नहीं। एक Composite Index जोड़ने से Manual Intersection Work समाप्त होगी और Cohort Report के साथ-साथ Platform पर 13 अन्य Queries एक साथ Accelerate होंगी।

तीसरी धीमी Query Player Cohort Report थी, जिसका उपयोग Product और CRM Team दोनों साप्ताहिक करती थीं। Gaming Mind ने एक Index Coverage Gap सतह पर लाई: तीन Columns जो इस Query के हर Version में साथ दिखते थे — Chain Identifier, Registration Date, और Game Category — प्रत्येक अलग-अलग Indexed था लेकिन कभी Composite के रूप में नहीं। हर Execution Query Time पर Manually Intersection Resolve कर रही थी, वह काम कर रही थी जिसे एक Composite Index ने पूरी तरह खत्म कर दिया होता। Gaming Mind ने नोट किया कि यह Column Combination Platform की चौदह अलग-अलग Queries में दिखती थी, यानी एक Index Addition से Cohort Report और तेरह अन्य Queries एक साथ Accelerate होती।

---

Priya: "इन Queries के चलने के दौरान Cluster में Resource Consumption दिखाओ।"

14-Day Resource Utilization — Peak Scheduled Report Windows

Date	Report Window	CPU Peak	Memory Peak	I/O Peak	Concurrent Slow Queries	Queue Cascade?
Day 1	09:00–09:45	74%	71%	68%	1	No
Day 2	09:00–09:45	78%	76%	72%	1	No
Day 3	09:00–09:45	81%	79%	75%	2	No
Day 4	09:00–09:45	76%	74%	71%	1	No
Day 5	09:00–09:45	82%	89%	84%	2	Yes
Day 6	09:00–09:45	77%	75%	73%	1	No
Day 7	09:00–09:45	79%	77%	74%	1	No
Day 8	09:00–09:45	83%	89%	85%	2	Yes
Day 9	09:00–09:45	75%	73%	70%	1	No
Day 10	09:00–09:45	84%	91%	87%	2	Yes
Day 11–14	09:00–09:45	72–78%	70–76%	67–73%	0–1	No

Risk Summary

Metric	Value
Concurrent Slow Query Runs के दौरान Memory Ceiling	89–91%
पिछले 10 दिनों में Cascade Events	3
Cascade Trigger	GGR Reconciliation + Player Activity एक साथ चलना
Risk Classification	🔴 Cluster Stability Risk

⚠️ Gaming Mind flags: हर CPU और I/O Utilization Spike Scheduled Report Runs के साथ मेल खाती है। पिछले 10 दिनों में 3 बार, GGR Reconciliation और Player Activity Reports के Concurrent Execution ने Memory को 89% से ऊपर धकेला, Queue Delays Trigger हुई जो अन्य Workloads तक Cascade हुई — जिसमें Finance CFO Timeout भी शामिल है। यह सिर्फ एक Slow Query समस्या नहीं है। यह एक Cluster Stability Risk है।

Gaming Mind ने तीन Slow Query Windows को NeonEdge के Cluster Resource Heatmap पर पिछले दो हफ्तों के लिए Overlay किया। Pattern अचूक था: CPU और I/O Utilization में हर Spike Scheduled Report Runs के साथ मेल खाता था, और Cluster पहली दो Queries के Concurrent Execution के दौरान Memory पर Near-capacity तक पहुँच रहा था। पिछले दस दिनों में तीन बार, GGR Reconciliation और Player Activity Reports के Concurrent Execution ने Memory Utilization को 89% से ऊपर धकेल दिया था, जिससे Query Queue Delays Trigger हुई जो अन्य Workloads तक Cascade हुई — जिसमें CFO ने जो Finance Timeout Experience किया वो भी शामिल था। यह सिर्फ एक Slow Query समस्या नहीं थी। यह एक Cluster Stability Risk था।

---

Priya: "मैं इन तीन Fixes को कैसे Prioritize करूँ? पहले कौन सा करूँ?"

Fix	Query	Estimated Speedup	Implementation Effort	Deployment Risk	Queries Impacted	Recommended Order
Composite Index जोड़ें (chain_id + reg_date + game_cat)	Player Cohort Report	~9x	Low (< 1 hr)	बहुत कम	14 queries	1st — आज Deploy करें
Join Order Rewrite (filter पहले, expand बाद)	Player Activity Report	~6x	Medium (3–4 hr)	Low (Staging में Test करें)	1 query	2nd — Staging के बाद Deploy करें
Table Scan से पहले Date Predicate जोड़ें	GGR Reconciliation	~12x	Medium (2–3 hr)	Medium (Finance Schedule Dependency)	1 query + caching eligibility	3rd — अगले Finance Maintenance Window में

Scoring Detail

Fix	Speedup Score	Effort Score	Risk Score	Impact Breadth Score	Total Priority Score
Composite Index	3/5	5/5	5/5	5/5	18/20
Join Rewrite	4/5	3/5	4/5	2/5	13/20
Date Predicate	5/5	3/5	3/5	3/5	14/20

⚠️ Gaming Mind flags: पहले Composite Index Deploy करें — सबसे कम Risk, सबसे तेज़ Implementation, Platform की 14 Queries में सबसे व्यापक Positive Impact। GGR Join Rewrite में सबसे ज़्यादा Individual Speedup (अनुमानित 12x) है लेकिन Finance के सटीक Report Parameters के विरुद्ध Staging Validation की आवश्यकता है। Table Scan Fix को Deployment से पहले Finance के Maintenance Window के साथ Coordinate किया जाना चाहिए।

Gaming Mind ने एक Priority Matrix तैयार की जिसने प्रत्येक Fix को चार Dimensions पर Score किया: Estimated Speedup, Implementation Complexity, Deployment Risk, और Downstream Impact की Breadth। Composite Index पहले Ranked था — सबसे कम Risk, सबसे तेज़ Deploy, और Platform की चौदह प्रभावित Queries में सबसे व्यापक Positive Impact। GGR Join Rewrite दूसरे Rank पर थी: सबसे ज़्यादा Individual Speedup अनुमानित बारह गुना सुधार पर, लेकिन Deploy से पहले Finance के सटीक Report Parameters के विरुद्ध सावधानीपूर्वक Testing की आवश्यकता थी। Unfiltered Table Scan Fix तीसरे Rank पर थी — भी High Impact, लेकिन Finance द्वारा Fixed Weekly Schedule पर चलाई जाने वाली Report में Date-filter Change शामिल था, जिसका मतलब था Deployment Window Coordinate करना। Gaming Mind ने Index पहले Deploy करने, Join Rewrite को Staging में Test करने, और Table Scan Fix को अगले Finance Maintenance Window के लिए Schedule करने की सिफारिश की।

---

Priya: "अगर मैं तीनों Fix करूँ तो Estimated Total Speedup क्या होगा?"

Projected Post-Optimization Performance

Query	Before	After	Speedup
GGR Reconciliation Report	41.2 sec	3.4 sec	~12x
Player Activity Report	31.0 sec	4.8 sec	~6x
Player Cohort Report	28.3 sec	3.1 sec	~9x
Combined avg report generation	45.0 sec	< 4.0 sec	> 11x

Cluster Resource Headroom

Metric	Before Fixes	After Fixes	Change
Memory Utilization (Concurrent Report Runs)	89% (ceiling)	~34%	-55pp
Queue Cascade Events per 10 days	3	0 (projected)	Eliminated
CFO Report Timeout Risk	Active	None	Eliminated

Secondary Benefit — GGR Reconciliation Caching

Detail	Value
Post-fix Caching Eligibility	Yes (Date Predicate Pre-computation Enable करता है)
Estimated Monthly Compute Cost Reduction	~60%
इस Benefit को Flag करने वाला Module	Cost Optimization

⚠️ Gaming Mind flags: तीनों Fixes मिलकर Average Report Generation Time को 45 सेकंड से 4 से कम करने का Projection है — 90%+ कमी। Peak Scheduled Runs के दौरान Cluster Memory 89% से ~34% तक गिर जाएगी, Cascade Queue Risk पूरी तरह समाप्त। GGR Reconciliation Fix Pre-computation Caching Eligibility भी Unlock करती है, जिससे उस Report की Monthly Compute Spend लगभग 60% कम होने का Projection है।

Gaming Mind ने Combined Effect Model किया। तीनों Fixes मिलकर Average Report Generation Time को पैंतालीस सेकंड से चार से कम करने का Projection था — नब्बे प्रतिशत से अधिक की कमी। Peak Scheduled Runs के दौरान Cluster Memory Utilization वर्तमान 89% Ceiling से लगभग 34% तक गिरने की उम्मीद थी, Queue Cascade Risk पूरी तरह समाप्त। Projection ने एक Secondary Benefit भी Flag किया: Unfiltered Table Scan Resolve होने पर, GGR Reconciliation Report Pre-computation Caching के लिए Eligible हो जाएगी, जिसे Gaming Mind के Cost Optimization Module ने Monthly Basis पर उस Report की Compute Spend में लगभग साठ प्रतिशत की कमी Estimate की।

"मैं उम्मीद कर रही थी कि Log Files में दोपहर बिताएगी। Gaming Mind ने बीस मिनट में तीन Queries Ranked, Profiled, और Prioritized कर दिए। उसने मुझे उन्हें Fix करने का Order भी बताया। मुझे बस Code लिखना था।"

— Priya Desai

---

परिणाम

20 मिनट में Cold Start से जांच पूरी

Priya के पास Query Performance के लिए कोई Pre-built Dashboards नहीं था और Trace करने के लिए कोई Open Incident नहीं था। Gaming Mind ने Telemetry Pull की, Offenders को Ranked किया, और एक ही Conversation में Deployment-ordered Fix List तैयार की। कोई Log Files नहीं खोले, कोई Support Tickets File नहीं किए, कोई Engineers दूसरे काम से नहीं खींचे।

तीन अलग-अलग Problem Types में तीन Root Causes पहचाने

प्रत्येक Slow Query का एक ढाँचागत रूप से अलग कारण था — एक Unfiltered Historical Scan, एक Suboptimal Join Order, और एक Missing Composite Index। Gaming Mind ने तीनों का निदान किया और प्रत्येक को सादे शब्दों में समझाया जो Priya Engineering Team को बिना Translation के सीधे Communicate कर सकती थीं। जांच ने ऐसी समस्याएं सतह पर लाईं जो महीनों से जमा हो रही थीं, न कि केवल पिछले अड़तालीस घंटों में Report किए गए लक्षण।

Fixes Deploy होने के बाद 12x औसत Speedup

Composite Index उसी दोपहर Live हो गया। Join Rewrite दिन के अंत तक Staging Tests Pass हो गई और अगली सुबह Deploy हुई। Table Scan Fix Finance के साथ Coordinate की गई और अगले Maintenance Window में Deploy की गई। तीनों बदलावों के बाद, Average Report Generation Time पैंतालीस सेकंड से तीन सेकंड और बयालीस सेकंड तक गिर गई — Platform की खुद की Telemetry के विरुद्ध Measured बारह गुना सुधार।

Incident बनने से पहले Cluster Stability Risk समाप्त

Memory Utilization Ceiling — जो Concurrent Report Runs के दौरान चुपके से 89% Push हो रही थी — Fixes के बाद 34% तक गिर गई। पिछले दस दिनों में जो तीन Cascade Events हुए थे वे एक Cluster के Early Warning Sign थे जो Load के तहत Failure की तरफ बढ़ रहा था। Gaming Mind ने इस Risk को Resource Heatmap Analysis से Surface किया; इसके बिना, अगली Incident संभवतः एक High-traffic Weekend Session के दौरान पूरे Report Outage की होती।

Reconciliation Report के लिए Monthly Compute Cost 60% कम होने का Projection

Cost Optimization Module ने GGR Reconciliation Report की Post-fix Pre-computation Caching Eligibility Flag की। Priya की Team ने Initial Fixes के दो हफ्ते बाद Caching Layer Implement की, और उसके बाद के महीने का उस Report Workload के लिए Infrastructure Bill Prior Baseline के अड़तीस प्रतिशत पर आया — Projection से थोड़ा बेहतर।

"Cluster तीन बुरे Sundays से एक Real Outage से दूर था और हमें पता नहीं था। Performance Investigation ने Slow Queries ढूंढे, लेकिन Resource Heatmap ने Stability Risk ढूंढा। वो हिस्सा था जिसने मुझे डराया — और वो हिस्सा जिसके लिए मैं सबसे ज़्यादा खुश हूँ कि हमने उसे Catch किया, उससे पहले कि वो हमें Catch करता।"

— Priya Desai, CTO, NeonEdge