API Performance Optimization — Cut Your Response Times from Seconds to Milliseconds

API performance problems cluster around four areas: database, external services, computation, and serialization.

Database: The most common bottleneck. N+1 queries, missing indexes, full table scans, and excessive query count per request account for 70-80% of API latency in the applications we audit. A single endpoint might fire 50 database queries to build its response when 2-3 well-crafted queries would produce the same result.

External Services: Calling third-party APIs synchronously in the request path adds their latency to yours. If you call a payment API (200ms), an email API (300ms), and a logging API (100ms) sequentially, you have added 600ms before your own code even runs. These should be parallelized or moved to background jobs.

Computation: CPU-intensive work in the request path blocks the event loop (Node.js) or occupies a thread (Python, Ruby). Image processing, PDF generation, data transformation, and report generation should not happen during the API request — they should be offloaded to worker processes or serverless functions.

Serialization: Converting large database result sets to JSON is surprisingly expensive. Serializing 10,000 rows with nested relationships can take hundreds of milliseconds. Pagination (limiting result sizes), sparse fieldsets (returning only requested fields), and efficient serializers reduce this overhead.

Profiling: We enable query logging and APM tracing to identify the slowest endpoints and the specific operations within each endpoint that consume time. We measure database query count and time, external API call time, application processing time, and serialization time separately. This pinpoints exactly where the time goes.

Query Optimization: We rewrite the most expensive queries using EXPLAIN ANALYZE to understand execution plans. We add indexes for common query patterns, replace N+1 patterns with JOIN or batch loading (Prisma's include, Django's select_related, Rails' includes), and use database-side pagination with cursor-based pagination for large datasets.

Response Caching: We implement HTTP caching headers (ETag, Cache-Control, Last-Modified) for endpoints that serve data that does not change per-request. For authenticated endpoints, we use Redis caching at the service layer with TTL-based or event-based invalidation. Cache keys are designed to partition correctly by user, locale, and query parameters.

Async Processing: We move slow operations out of the request path. Email sending, notification dispatching, analytics events, and audit logging are pushed to a message queue (SQS, Redis, RabbitMQ) and processed by background workers. The API responds immediately with a 202 Accepted status, and the client can poll or listen via WebSocket for completion if needed.

Connection Management: We configure connection pooling for database and external HTTP clients. PgBouncer for PostgreSQL, HTTP keep-alive with connection reuse for external APIs, and Redis connection pooling to prevent connection churn. We also configure appropriate timeouts so a slow external service does not tie up your connection pool.

A comprehensive API performance optimization:

• Performance profile — endpoint-by-endpoint latency breakdown with bottleneck identification
• Query optimization — rewritten queries, new indexes, N+1 elimination
• Response caching — HTTP cache headers and Redis caching for appropriate endpoints
• Async processing — slow operations moved to background workers with queue infrastructure
• Connection pooling — database and HTTP client connection management
• Pagination — cursor-based pagination for large datasets
• Monitoring — per-endpoint latency tracking with p50/p95/p99 dashboards and alerting
• Before/after metrics — documented response time improvement across all optimized endpoints