A senior DevOps engineer explains why loading 30,000 items in a UI is a critical anti-pattern and provides three real-world solutions, from emergency hotfixes to proper architectural redesigns.

The 30k Item Problem: A Senior Engineer’s Guide to Not Crashing Production

I still remember the 2 AM PagerDuty alert. A core service, the one that handled all customer account data, was completely unresponsive. The entire support dashboard was a sea of 504 Gateway Timeouts. We spent an hour combing through logs on prod-api-04, checking the database replicas, and suspecting a DDoS attack. The cause? A well-intentioned junior developer had pushed a “small UI improvement” an hour earlier. He’d changed the customer list view from showing the first 100 entries to showing… well, all of them. One of our enterprise clients had just crossed the 30,000-user mark. The API, the database, and every support agent’s browser just gave up trying to render a single, massive table. We’ve all been there, and trust me, it’s a lesson you only need to learn once.

First, Let’s Understand Why Everything Breaks

This isn’t just about “a lot of data.” It’s a systemic failure across your entire stack. When you ask a web application to fetch and render 30,000 of anything, you’re creating three distinct bottlenecks that will kill your performance:

• The Database: Your database, let’s call it prod-db-01, has to pull all 30,000 rows. Even with indexes, that’s a lot of I/O. It then has to serialize that data and send it over the network to your API server.
• The Backend API: Your API server now has to hold that massive dataset in memory, process it, and serialize it into a huge JSON payload. We’re talking potentially megabytes of data for a single HTTP request. This chews up memory and CPU, starving other, more reasonable requests.
• The Frontend (Browser): This is often the first thing to die. The browser has to download that giant JSON payload, parse it, and then—the real killer—try to render 30,000 DOM elements. The user’s machine will grind to a halt, the tab will become unresponsive, and they’ll get the dreaded “This page is not responding” dialog.

Trying to solve this problem by just “making the server bigger” is like trying to fix a leaky pipe with a bigger bucket. You’re ignoring the root cause. Let’s fix the pipe.

The Solutions: From Hotfix to Architecture

Depending on whether your hair is on fire or you’re in a calm planning meeting, your approach will differ. Here are the three ways I’ve tackled this problem in my career.

Solution 1: The “Stop the Bleeding” Quick Fix

It’s 2 AM and production is down. You don’t have time to re-architect anything. Your only goal is to get the system stable. You need to stop the query from ever trying to fetch 30k rows. The fastest way is to enforce a hard limit in the backend code.

Find the data access layer code that fetches the items. It probably looks something like this:

-- BEFORE THE FIX
SELECT id, name, email, created_at FROM customers WHERE tenant_id = ? ORDER BY created_at DESC;

You are going to add a LIMIT clause. Right now. You are not going to ask for permission. You are going to save production. A reasonable number is 100 or 1000, depending on your UI. This is a temporary band-aid, but it’s an effective one.

-- AFTER THE QUICK FIX
SELECT id, name, email, created_at FROM customers WHERE tenant_id = ? ORDER BY created_at DESC LIMIT 100;

This is hacky. The UI won’t know why it’s only getting 100 results, and there’s no way to see the rest. But the site will be back up. You’ve bought yourself time. Now, go create a high-priority ticket to fix this properly.

Solution 2: The Permanent Fix (Server-Side Pagination)

This is the correct, standard way to handle large datasets. Instead of asking for “all the items,” the frontend will ask for a specific “page” of items. The backend API needs to be updated to support this.

Your API endpoint will change from GET /api/customers to something like GET /api/customers?page=1&limit=50.

The backend logic will use these parameters to construct a paginated query:

-- PAGINATED QUERY (PostgreSQL/MySQL)
-- For page=2 and limit=50, the offset would be (2-1) * 50 = 50.
SELECT id, name, email, created_at
FROM customers
WHERE tenant_id = ?
ORDER BY created_at DESC
LIMIT 50 OFFSET 50;

Crucially, your API response should not just return the data. It needs to return metadata so the frontend can build the pagination controls (e.g., “Page 2 of 600”, “Next”, “Previous”).

{
  "metadata": {
    "page": 2,
    "per_page": 50,
    "total_items": 29876,
    "total_pages": 598
  },
  "data": [
    { "id": "...", "name": "Customer 51", ... },
    { "id": "...", "name": "Customer 52", ... },
    ...
  ]
}

This is the industry-standard solution. It’s efficient, scalable, and provides a predictable user experience.

A Word of Warning: Be wary of “infinite scroll.” While it can feel slick, it’s just pagination without explicit controls. If not implemented carefully (with virtualization on the frontend), you can end up right back where you started, with thousands of DOM elements crashing the browser.

Solution 3: The “Nuclear” Option (Rethink the User Experience)

Sometimes, even pagination isn’t the right answer. Take a step back and ask: “Why does a user need to see 30,000 items in a list?” The answer is almost always: they don’t. What they actually want to do is find a specific item, or analyze the entire dataset.

A list is a terrible tool for these jobs. Instead of displaying a giant list, give the user the tools they actually need:

• Robust Search & Filtering: Build a powerful search API. Let the user filter by date ranges, status, name, or any other relevant attribute. The initial view can be empty or show the 10 most recent items, prompting the user to search.
• Asynchronous Export: If they truly need all the data, they probably want it in a spreadsheet. Add an “Export to CSV” button. When clicked, this should trigger a background job on the server. The job queries the database, generates the file, and then emails the user a link to download it. This offloads the entire heavy lifting from the user’s browser and the web server process.

This approach requires more work, but it often results in a vastly superior and more useful product. You’re solving the user’s actual problem, not just their stated request.

Comparison of Solutions

So, the next time someone on your team suggests fetching an entire table to display in a UI, you can gently guide them away from the cliff. It’ll save you, your users, and your on-call engineers a lot of pain.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions