Is AWS Step Functions the right fit for a unified orchestration API, or is this becoming an anti-pattern?
I'm currently working on an architecture study for a large enterprise and would really appreciate feedback from architects who have built production systems with AWS Step Functions.
Context
The main use case is booking creation.
Clients call a single REST API to create a booking, but the request has to coordinate several downstream systems before the booking can finally be created in one of two different ERP systems.
A simplified flow looks something like this:
Validate the request.
Perform business and technical validations.
Retrieve reference data from multiple services.
Enrich the request with additional information.
Apply orchestration-specific business rules (routing, sequencing, conditional execution, etc.).
Call the appropriate ERP to create the booking.
Return a unified response regardless of which ERP handled the request.
Some post-booking activities may eventually become asynchronous, but the booking creation itself is a synchronous API where latency is important.
The ERP remains the owner of the booking domain and its core business rules. However, the orchestration layer inevitably contains some orchestration-specific logic because it has to coordinate multiple systems before the ERP can be called.
The discussion
One proposal is to implement the orchestration using AWS Step Functions Express, with Lambda tasks calling the downstream services.
The alternative is to build a custom orchestration service (for example Spring Boot) exposing the unified REST API and coordinating all of these calls internally.
My concern
My understanding has always been that workflow engines provide the most value when they orchestrate existing business capabilities into a larger business process.
For example:
Validate customer
Reserve inventory
Process payment
Create shipment
Send notification
Each of these is already a well-defined business capability, and the workflow coordinates them.
In our case, however, the API itself represents one business capability: Create Booking.
While there are multiple downstream calls, validations, enrichments and orchestration decisions, they all exist solely to fulfill this single business capability.
My concern is that choosing Step Functions may encourage us to decompose this capability into workflow states simply because we're using a workflow engine, rather than because those states represent reusable or independently meaningful business capabilities.
At the same time, I also recognize that there are legitimate orchestration concerns (routing, sequencing, retries, compensations, conditional paths, observability, etc.) that Step Functions is designed to solve.
So I'm trying to understand where experienced architects draw the line.
Questions
Does this sound like a good use case for Step Functions Express, or would you lean toward a custom orchestration service?
At what point does a complex synchronous API become better suited for a workflow engine rather than application code?
Have you seen Step Functions successfully used as the primary implementation behind high-throughput synchronous REST APIs?
Where do you generally draw the architectural boundary between:
a workflow engine,
an orchestration service,
and a normal application containing orchestration logic?
I'm not looking for "Step Functions is good" or "Spring Boot is better." I'm more interested in the architectural principles you use to decide where a workflow engine adds value versus where it introduces unnecessary complexity.