Build1 publisher3 min readPublished
Step Functions bills every retry attempt as its own state transition
An engineer who runs Camunda 8 in production priced the AWS alternative from its docs and found the billing unit is the state transition, so the same order costs more on the days its steps have to retry and roll back.
The Engineer · Build desk
What happened
- A dev.to post sets AWS Step Functions against Camunda 8 for sagas, noting both are central coordinators that hold the process state, drive the steps in order and trigger the rollback when a step breaks.
- The Step Functions saga is written in Amazon States Language, plain JSON that AWS runs, with no broker, cluster or exporter of your own to keep alive.
- Standard Workflows, the option for long-running sagas, bill per state transition, with the first 4,000 a month free and $0.000025 for each one after that.
- Every retry attempt counts as its own billed state transition, which the post flags as the pricing detail teams miss.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Billing by transition ties the spend curve to other people's uptime: the machine transitions most while dependencies are flapping, and the team running the saga pays for each attempt.
- exposure A rollback branch that was never wired does not produce an error, so a half-finished order sits in the data with nothing pointing at it.
- decision The choice in front of a team is which on-call it wants: sizing and tuning a Zeebe cluster, or a transition bill it cannot forecast without knowing its own failure rate.
- constraint For sagas that run long, Standard Workflows are the fit, so the per-transition meter comes attached to the only workflow type that suits the pattern.
Count the transitions on the machine the post publishes. The happy path enters three task states: reserve inventory, charge the card, ship [5]. The first 4,000 transitions a month are free [8], so three per order covers roughly 1,333 clean sagas before the meter starts [1].
Now break something. The Retry block in the example sits on ReserveInventory, with ErrorEquals States.TaskFailed, MaxAttempts 3, IntervalSeconds 1 and BackoffRate 2.0 [4]. Each attempt bills separately [9]. Read MaxAttempts as three retries after the first try, and a reserve step that flaps through all of them before succeeding, followed by a charge that fails into ReleaseInventory and then SagaFailed, comes to six billed transitions, seven if the terminal Fail state counts, against three on the happy path [2]. Call it a factor of two to 2.3. The multiplier shows up on the afternoon your payment provider is having a bad hour.
The unit price is where I would push back on the framing. Seven transitions is $0.000175 [3]. To spend $1,000 in a month at $0.000025 each you need 40 million transitions [4]. For a bill to grow faster than traffic [13], the saga has to carry far more than five states, or a wait-and-poll loop that re-enters a Choice state on a timer. Neither is in the published example, which has five states and no waits [5].
The compensation design is the part that would worry me more, and it is free. Step Functions has no primitive that compensates a whole saga [6]. If Ship fails, its Catch has to route to a state that refunds the payment and then to a state that releases the inventory, in that order [7]. "The state machine is honest and explicit, which is a nice way of saying verbose and entirely your responsibility," the author wrote [10].
On the Camunda side the post names one concrete burden: tuning Zeebe partitions at 2am [13]. The managed engine's pitch is the inverse of that: the broker, the cluster and the exporter are not yours to run [3]. "We run Camunda 8 in production for credentialing and scheduling workflows, so I've lived one of these; the other I've read the docs on and priced out for real proposals," the author wrote [11]. The text breaks off mid-sentence in the billing paragraph, before any Camunda figures appear [15]. The evidence supports the asymmetry in who owns which failure, and it does not support a cost comparison between the two engines.
The author's case for a central coordinator at all is a debugging question: with choreography, nobody can answer why order 8842 is stuck, because the state is smeared across six services' logs [14]. Which burden you can afford is the question the post frames as "which failure is yours to own" [12].
What to watch
- Whether the Camunda 8 half of the comparison, when published, prices Zeebe cluster ownership in units a buyer can compare.
- Any change by AWS to Standard Workflow transition pricing or the free monthly allowance.
- Whether teams start emitting transition counts per execution, so a retry storm shows up in telemetry before it shows up on the invoice.