How I Designed a Scalable Dashboard With Zero API Cost During My Internship
Updated: Dec 20, 2025
This article walks through how I built a real-time, scalable dashboard for 200K+ users during my internship without incurring any extra API cost, by choosing a cost-efficient backend architecture and driving performance through prioritization and testing.
A real-time dashboard. High-volume data. Zero API cost.
That was the challenge in my internship, and here’s how I solved it.
What started as a simple requirement, “we need a new dashboard feature for our 2 lakh+ users”, quickly turned into a complete product thinking exercise involving stakeholder alignment, prioritization, performance testing, database strategy, and multiple UI iterations.
This is the story of how I built it.
Starting With the Basics: What Problem Are We Solving?
Before touching any design tool, we aligned with the product and tech teams on two core needs:
The dashboard must be lightweight and responsive
It should show real-time or near-real-time data
It should put zero extra load on APIs or Amazon RDS
To define what actually needed to be built, I used the MoSCoW prioritization framework.
Category | Features Considered |
Must-Have | • Net Income (with Revenue and Expenses) • Total Documents Created and Amount, Subscription Plan Summary (including Expiry Date, Active Sub-users, SMS Balance Count, subscribed features) • Daily Outstanding List |
Should-Have | • Banner (as shown in mobile app) for updates/notifications • Monthly income breakdown (Graphical View - line/bar chart) |
Could-Have | • Data sync button • Branch-wise Breakdown • Download Report Button |
Won’t-Have (for now) | • Advanced Filters with custom date option (due to current technical constraints) |
This simple framework saved us from scope creep, aligned the entire team, and gave developers a clear execution path.
Database Strategy: The Real Challenge
The main challenge: How do we show real-time data without increasing API count or RDS costs?
We evaluated 3 options:
Option 1: Redis Cache Server
Great for speed, but adds infra cost.
Option 2: Read directly from RDS in real time
Accurate, but increases RDS read load.
Option 3: Local lightweight database on EC2
Should sync periodically & serve dashboard data instantly.
Final Choice → Option 3: Local DB on EC2
Why?
Zero additional API cost
Minimal latency (almost the same as RDS in our tests)
Reduced RDS load
High concurrency performance
Full control over infra
A database can be used for overall user analysis
Perfect for dashboards that need frequent reads
This gave us a scalable, cost-efficient backend that wouldn't impact core system performance.
Performance Testing: Proving the Architecture
We conducted two realistic tests:
A. Single Connection, Bulk Data Fetch
Up to 25,000 records
RDS was slightly faster, but the difference was negligible
EC2 nearly matched performance after 10,000 records
B. Multiple Connections, Single Row Fetch
Simulated real user behavior.
EC2 response time: ~0.286–0.320s
RDS response time: ~0.405–0.407s
Conclusion: Local DB in EC2 performed better under high concurrency and was more cost-efficient → exactly what a dashboard needs.
Wireframes to Final UI:
Version 1:
A basic layout, too simple for complex data.
Version 2–3:
Added graphs, grid layouts, and better spacing.
Version 4 (After Implementation):
A clean, responsive layout that balanced:
Readability
Data density
Visual hierarchy
Mobile adaptability
This went into development and became the final live dashboard.
I later created a Dashboard Guide for internal teams covering:
Logic
Calculations
Section breakdowns
Sync cycles
This made cross-functional onboarding much smoother.
What I Learned
This internship dashboard taught me more about real-world product execution than any classroom could:
Prioritization decides whether the product succeeds
Backend decisions matter as much as UI design
Performance testing eliminates assumptions
Cost-aware architecture is a key PM skill
Iterating with tech teams builds better solutions
UI isn't just about looks; it's about clarity, speed, and user trust
I didn’t just design a dashboard. I helped build a scalable product feature
This experience strengthened my skills in product thinking, UX, technical feasibility, cost-optimization, and cross-team collaboration skills that I carry into every project now.
