Locate the boundary of a runtime change
The process returning a web response is not always the process doing all the work. A platform change needs to account for the components that can continue independently.
Follow the work after the response
Consider a simplified application with an HTTPS entry point, a web runtime, a background worker and a database. The web process can accept a request and queue a job. Its response can finish while the worker continues processing that job.
The illustration separates those components so their configuration and evidence can be inspected. It describes a hypothetical arrangement, not a client platform or a required design for every application.
Request entry
A client reaches the HTTPS entry point.
- Platform work
- TLS termination, ingress routing, request limits and network access.
- Application behavior
- The routes, authentication behavior and response the application provides.
- Relevant evidence
- A request through the intended entry route, with the entry and application responses distinguished.
Application runtime
The web process handles the request and uses its dependencies.
- Platform work
- Runtime version, environment configuration, resource limits and deployment settings.
- Application behavior
- Request handlers, dependency calls, query behavior and the decision to queue background work.
- Relevant evidence
- Startup and representative request behavior using the runtime’s intended identity.
Background worker
Queued work can continue after the web response ends.
- Platform work
- Worker count, concurrency, shutdown behavior and connectivity to the queue and database.
- Application behavior
- Job semantics, safe repetition and the treatment of partially completed work.
- Relevant evidence
- Job duration, queue age and the agreed interruption test.
Database dependency
Web and worker processes may share the same connection limit.
- Platform work
- Service configuration, runtime access, connection limits and the agreed backup setup.
- Application behavior
- Queries, transactions, schema changes and compatibility with the running application versions.
- Relevant evidence
- Application access and compatible reads/writes against the intended database state.
Entry routing and application behavior meet at a boundary
The entry configuration can control TLS termination, routing and request limits. The application determines which routes it serves and how a request is authenticated and handled. A rejected request may never reach the application, so application logs alone may not explain the failure.
Inspect the status and relevant evidence at each boundary. A timeout at the entry point, an application exception and a failed database call can produce similar symptoms for the person using the service while requiring different changes.
Worker concurrency changes pressure on a dependency
Increasing the number of workers can start more jobs at once. If each job opens database connections, the extra concurrency can consume a shared limit also needed by web requests. The database limit can be reached while the worker still has spare CPU.
Review job duration, queue age, connection use and the application’s handling of interruption. A deployment should define how existing work drains or resumes when a worker stops. The application decides whether a job can be repeated safely; infrastructure settings cannot infer that from the queue alone.
Divide the assignment by the change being made
Platform work can cover runtime configuration, ingress, network access, deployment settings and observability. Application work can include route behavior, job semantics, database queries and the logic that decides whether an operation can be repeated.
The same engineer may work across those areas, but the assignment still needs to identify the changes being commissioned. A runtime adjustment does not automatically include rewriting a query or changing how the application handles a partially completed operation.
Test the boundary that actually changed
For a routing change, exercise the intended route through the entry point. For a worker change, inspect startup, a representative job and its behavior when the process stops under the agreed test conditions. For a database-access change, use the application’s intended identity.
Validate the operation through its changed component. Host health, a build result and an open TCP connection each describe only part of that path.