CRUD is a useful starting point, but it is a poor performance strategy. Create, read, update, and delete describe what an API can do; they say almost nothing about how it behaves when traffic rises, records multiply, clients retry, and databases become shared bottlenecks.

Predictable performance comes from making costs visible and bounded. A well-designed API should not merely be fast in a development environment with a small dataset. It should make it difficult for a single request, an eager client, or an unfortunate query plan to create a surprising amount of work.

Start with the work a request is allowed to cause

Every endpoint is a contract, and the response schema is only part of that contract. The hidden part is operational: how many rows may be read, how much data may be returned, which dependent services are contacted, and whether repeating the request is safe.

Consider a familiar endpoint:

GET /orders

Without constraints, it invites ambiguity. Does it return every order? Does each order include its items, customer, payments, and shipment history? Can clients sort by any field? Those choices can turn a simple read into a large query, several joins, and a response that grows without limit.

A more deliberate design puts limits at the boundary:

GET /orders?limit=50&cursor=eyJpZCI6MTAyNH0

Cursor pagination is often preferable to offset pagination for large, changing collections. An offset such as OFFSET 50000 can force the database to scan or discard a substantial number of rows before it returns a page. A cursor tied to a stable, indexed ordering lets the database continue from a known position.

The important point is not that every endpoint must use cursors. It is that collection endpoints need an explicit upper bound, a deterministic order, and an index that supports the query actually being made.

Design queries before designing convenience

Backend code can make expensive work look harmless. In PHP, an ORM relationship accessed inside a loop is concise, but it may execute one query per result. The classic N+1 problem is not a framework-specific failure; it is a mismatch between an API response and its data access plan.

$orders = $repository->findRecentOrders();

foreach ($orders as $order) {
    $customerName = $order->customer()->name();
}

If customer() loads data on demand, a page of 50 orders may create 51 database queries. The repair is usually to fetch the needed customer data in a bounded eager-loading query, a join, or a purpose-built read model. Which option is best depends on the schema and the response shape, but the endpoint should be assessed in queries and rows, not just lines of application code.

Make index ownership explicit

An API filter is also a database requirement. If clients can request orders by account, status, and creation time, the supporting index must reflect the filtering and sorting pattern. Adding indexes blindly is not a solution: each index consumes storage and adds write cost. The useful discipline is to identify the few query shapes an endpoint promises, then verify them with the database’s query plan tools against realistic volumes.

Be especially cautious with flexible “filter by anything” endpoints. They offer convenience at the cost of an open-ended query surface. A smaller set of documented filters is easier to index, test, secure, and support.

Separate list views from detail views

A common source of unstable latency is treating one representation as suitable everywhere. A dashboard list usually needs identifiers, status, timestamps, and a few summary fields. A detail screen may need line items, notes, audit information, and related resources.

Those are different workloads and should usually be different responses. Returning a compact list representation keeps indexes useful, memory consumption lower, JSON encoding cheaper, and network payloads predictable. A detail endpoint can then load the richer graph when a user asks for it.

• Use collection endpoints for bounded summaries.
• Use detail endpoints for a clearly defined resource graph.
• Offer explicit expansion only when it has strict limits and known costs.
• Keep rarely used or large relationships behind separate endpoints.

This is not an argument for creating an endpoint for every screen. It is an argument for resisting a universal response object that attempts to satisfy every future consumer.

Treat writes as workflows, not only mutations

CRUD language can obscure the operational nature of writes. A request that creates an invoice, sends an email, reserves inventory, and calls a payment provider is not a simple database insert. It is a workflow with partial failure modes.

Start by making retry behavior intentional. Network failures can occur after a server has completed a write but before the client receives the response. For externally initiated creation requests, an idempotency key can let the server recognize a retry and return the original result rather than create a duplicate.

POST /payments
Idempotency-Key: 4a6e0d3f-unique-per-attempt

The server must store that key with enough context to distinguish a legitimate retry from a different request that reused the same key. It should also define what happens while the first request is still running. Idempotency is a complete behavior, not just a request header.

For slow work, prefer an asynchronous boundary. Persist the user-visible state transactionally, enqueue a job through a reliable mechanism, and return a representation of the accepted work. Workers should be retry-safe, observable, and able to handle duplicate delivery. Avoid holding an HTTP request open while it performs work whose duration depends on another system.

Use caching as a contract, not a rescue plan

Caching can reduce load dramatically, but a cache that is added after latency becomes painful often creates correctness surprises. Decide what may be stale, for how long, and who invalidates it. Read-heavy public resources may work well with HTTP cache headers and conditional requests. Internal computed results may need an application cache with a short, explicit lifetime.

Do not cache blindly around a slow query. First confirm that the query has appropriate bounds and indexes. Otherwise, a cache miss remains expensive, invalidation remains fragile, and the system becomes harder to reason about.

Make performance observable in deployment

Docker can make local setup consistent, but it does not make production behavior predictable by itself. A container still has memory limits, CPU scheduling, connection pools, timeouts, and shutdown behavior to manage. A PHP application that opens too many database connections can overwhelm a database even when every container appears healthy.

Define timeouts at each dependency boundary, and make sure they compose sensibly. A request timeout should leave room for the application to handle a database or upstream timeout. Log a request identifier, endpoint, status code, duration, and meaningful failure category. Measure database query count and duration where practical. These signals turn “the API is slow” into a question that can be investigated.

Before deployment, test the failure paths that ordinary CRUD demos ignore: a repeated POST, a slow dependency, an empty page after a cursor, a deleted related record, a worker retry, and a database connection failure. Predictability is built as much in these paths as in the happy path.

Performance is a property of boundaries

The most durable API designs are not the ones with the most abstractions. They are the ones that state their limits clearly: bounded pages, deliberate query shapes, compact representations, retry-safe writes, explicit cache behavior, and measurable dependency costs.

CRUD remains useful vocabulary. It simply is not enough architecture. When an API makes its work visible and constrained, teams can evolve it with confidence—and users experience something more valuable than occasional speed: reliable behavior when the system is under pressure.