From the order to the worker
Follow a refund request from the model toward the payment service. The model recommends a refund; the application changes the order state and dispatches work to a worker. Google’s generally available Spanner queues combine the two database writes on that path. Approving the refund and creating its task commit in the same transaction. If the transaction fails, neither change takes effect. That gives the builder a useful component: storing the decision and creating the task no longer require separate commits to a database and a messaging service.[1]
The connection also covers work that should run later. Google’s example creates a four-hour timeout while waiting for human approval. When approval arrives, changing the order and deleting the still-pending task can share a transaction. A SQL assertion checks that deletion affected the expected number of rows. For a small team, the practical attraction is inspecting pending work and order state through the same query system. Investigating why work is waiting need not involve switching between application data and a separate queue dashboard.[1]
The worker introduces another step. It receives work through streaming SQL, obtains a lease and acknowledges completion. Google describes delivery as at least once and acknowledgement as at most once. Keeping those terms attached to the refund example is useful: delivery can repeat, while the acknowledgement has its own database behavior. A developer taking over the application can then ask which stage repeated. Receiving the same task again and causing the payment service to issue a second refund are different failure points.[1]
Put the experiment around the payment response
I would put the next experiment around the payment response. Since the order update and task insertion share a transaction, what happens if the worker stops after the outside service accepts the refund but before the task is acknowledged? That question follows from the published delivery and acknowledgement behavior. How the payment provider handles a repeated request remains application knowledge beyond those two atomic database writes. The queue design may help turn that boundary into a visible test case; the benefit depends on the outside service used by the application.[1]
I would retain the existing implementation, with its separate queue and transactional task table, as the baseline for the same experiment. Maintenance around approval, cancellation and redelivery is the first thing to measure. Spanner exposes pending work and execution history through SQL, a concrete feature supporting that inspection. Model selection is not the first variable here: the same model and refund policy can be used while comparing how the task flow is investigated. A useful result would be less reconciliation and failure investigation by the team in actual use.[1]
The task flow in return becomes tied to Spanner’s data model and GoogleSQL queue operations. Placing the queue beside the order table may reduce the number of separate components a small team manages; the application still designs the external call and its retry behavior. I would ask a team trying the feature for one demonstration: stop and restart the worker immediately after payment acceptance, then inspect the order, task and payment outcomes together. If that path is easy to explain, moving the queue into the database has concentrated development work somewhere more inspectable.[1]