Reducing an E-commerce API from 10s to Under 1s

Performance work starts with humility. When an API endpoint takes around 10 seconds, the first instinct is often to rewrite the obvious function. That is rarely the best first move.

The better path is to measure, isolate, and then change the smallest part of the system that explains most of the latency.

Start With a Trace

Before touching code, capture the request lifecycle with an APM tool or profiler. The goal is to answer basic questions:

• Is the time spent in Python, SQL, network calls, rendering, or serialization?
• Does the endpoint repeat the same query many times?
• Are expensive computations happening per record instead of per batch?
• Does the request depend on external services?
• Is the slow path common or tied to specific data?

Without this evidence, optimization becomes guessing.

Look for Multiplication

Most slow business APIs are not slow because of one dramatic line. They are slow because a reasonable operation is repeated too many times. This can appear as N+1 queries, repeated permission checks, repeated price computations, inefficient product availability calculations, or unnecessary serialization of large object graphs.

In ERP and e-commerce systems, multiplication hides inside business rules. Pricing, taxes, stock routes, customer-specific conditions, and catalog visibility can all look simple in isolation and become expensive under load.

Fix the Shape of the Work

Once the bottleneck is clear, the strongest optimization is usually structural:

• Batch database reads instead of querying per record.
• Push filtering and aggregation into PostgreSQL when appropriate.
• Cache stable intermediate results during the request.
• Remove duplicate computations.
• Avoid loading fields that the response does not use.
• Split synchronous and asynchronous responsibilities.

The goal is not clever code. The goal is less work.

Validate With Real Inputs

After the change, test with data that resembles production. A fix that works with 20 products may not work with 20,000. A query that is fine for one customer may be slow for customers with complex price lists, many addresses, or unusual tax rules.

Performance improvements should be validated with:

• Before-and-after timings.
• Query counts.
• Slow query logs or query plans.
• Representative business cases.
• Monitoring after deployment.

Make It Maintainable

The final step is to leave the system easier to understand. Add comments only where the business reason is not obvious. Add tests around the optimized path. Record the performance assumption that matters, such as avoiding per-line queries or keeping a computation batched.

Reducing an endpoint from 10 seconds to under 1 second is not magic. It is disciplined diagnosis, careful simplification, and respect for the business rules that made the endpoint complex in the first place.