Part 07 of 16 · Day 1 · 202 Accepted, correlation ID
Response before the result
Problem and experience
The API said 200. And what happened next?
The application takes minutes to process. The client needs to know we have accepted it, and to check how it turned out.
- POST /applications
- Waits for all services
- Timeout
- The client only knows “error”
From practiceWhat does your API return today when the work takes longer than a few seconds?
TakeawayLong-running work needs a different API than short work.
What it means
A synchronous “done” response does not work for long processes. The client needs an acknowledgement of receipt and a way to find out the result.
Why we use it
Otherwise it either waits or has to guess.
When it makes sense
For everything that depends on asynchronous processing.
Where it breaks
- Holding the HTTP connection open until everything completes.
- Returning 200 before the application has really been accepted.
- Having no operation identifier.
Imagine
The application takes ten minutes to process. The client submitted the form and sees only a spinner.
Acceptance and completion are two different responses.
Principle, application and exercise
202, an operation identifier and a causation trail
The API returns 202 Accepted and an operationId. Each event knows what triggered it. The client reads the operation status from a projection.
Client
- POST /applications
- 202 + operationId
- GET /operations/{id}
- Status: in progressfrom the projection
Context
- correlationIdholds the whole process
- causationIdwhat triggered the event
- Processing chain
Trade-offThe client has to be able to ask and wait. Identifiers must pass through all services and logs, otherwise we cannot stitch the chain together.
TakeawayThe Correlation ID links the process. The Causation ID shows what directly triggered the next step.
What it means
The Correlation ID links the messages of one process. The Causation ID points to the immediate message that caused the next one. They help reconstruct the processing chain, not reveal the client’s motives.
Why we use it
Without them, we trace what happened to an application by hand in the logs of ten services.
When it makes sense
Always for processes spanning multiple services.
Where it breaks
- The identifier gets lost when passing between services.
- Relying on time instead of a sequence number within the correlation.
- Confusing the time of an event with the time the system learned about it.
Imagine
The client submitted an application and received an operationId. Whenever they ask, they see the current status, and we can trace the whole chain by correlationId.
Operation status is data, not a question that has to be answered immediately.
Training for your team
Would you like this training for your team?
We run the training on your code and your domain problem. We agree the scope, dates and format with you.
Discuss the training →