Skip to content

Independent architecture study

Approved payments moving through events

Event-Driven Payment Processing on AWS

An approved payment still needs to reach the posting system safely. This independent architecture study turns saved authorisations into events, adds context and business checks, then buffers posting work so downstream capacity does not dictate every upstream step.

An independent architecture study based on public AWS guidance. A design exercise, not a client engagement.

Workload
Near real-time posting of approved payment authorisations
Constraint
Retries must not repeat financial effects or overwhelm downstream posting
Approach
Durable authorisations, event routing, idempotent processing and a posting queue
  • Up to 20%Graviton2 cost efficiencyPublished reference figure. The AWS guidance cites this potential efficiency for Arm-based Lambda; it is not a measured saving for this study or the whole pipeline.

What makes this difficult

  • Approval is not posting

    Saving an approved authorisation starts the posting journey, so the system must distinguish accepted work from a transaction confirmed downstream.

  • Retries carry financial consequences

    Repeated delivery is possible in an asynchronous pipeline, so duplicate checking and idempotent business processing need explicit design throughout the journey.

  • The slowest system still matters

    A queue absorbs bursts but cannot remove downstream limits, so posting throughput and growing backlogs must remain visible to operators.

Follow an approved payment

A saved authorisation becomes an event that is checked, enriched, evaluated and queued before the downstream system posts it.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  1. 01

    Save the approved payment

    Approves thepaymentAuthorisation appSaves theapprovalDynamoDB

    The authorisation application approves the payment and persists it in DynamoDB, giving the posting pipeline a durable starting record before asynchronous processing begins.

    Illustrative example Illustrative example: an approved authorisation is saved for processing.

  2. 02

    Turn the saved change into an event

    Saves theapprovalDynamoDBReads savedchangesEventBridge PipesChecks forduplicatesLambdaRoutes paymenteventsEventBridge

    An EventBridge pipe reads the table stream and uses a Lambda duplicate check before publishing accepted work to the custom event bus for further processing.

    Illustrative example Illustrative example: an accepted authorisation event reaches the bus.

  3. 03

    Add the missing account context

    Routes paymenteventsEventBridgeAdds accountcontextLambda

    A matching bus rule invokes the enrichment function, which queries metadata and publishes a new event containing context such as account type and bank details.

    Illustrative example Illustrative example: an enriched event includes the account context needed for rules.

  4. 04

    Apply the posting rules

    Routes paymenteventsEventBridgeAppliesbusiness rulesStep Functions

    The bus routes an enriched event to Step Functions, where the workflow applies business rules and publishes a further event only when those rules pass.

    Illustrative example Illustrative example: a passing event becomes eligible for the posting queue.

  5. 05

    Absorb the rush before posting

    Routes paymenteventsEventBridgeBuffers postingworkSQS

    A bus rule places passing work onto SQS, allowing approved payments to wait while the posting consumer processes messages within the downstream system’s capacity.

    Illustrative example Illustrative example: posting work waits in the queue during a traffic burst.

  6. 06

    Post and report the outcome

    Routes paymenteventsEventBridgeBuffers postingworkSQSRequests thepostingLambdaPosts thetransactionPosting system

    Lambda reads queued work, invokes the downstream posting subsystem and publishes a final event back to the bus, making the processing outcome available to subscribers.

    Illustrative example Illustrative example: a completed posting produces a final event.

  • Request
  • Data
  • Later, queued
  • Control

The hard part

Duplicate filtering is not the whole guarantee

The pipe can reject duplicates before routing, but a later posting attempt can still be retried. The guidance combines duplicate checking with idempotent Lambda processing. At the downstream boundary, the design must also establish how a repeated request is recognised and how an uncertain outcome is reconciled, so retries do not create repeated financial effects.

Receives savedchangesEventBridge PipesFiltersduplicatesLambdaRoutes stagedeventsEventBridgeHolds passingworkSQSHandles repeatattemptsLambdaConfirms postingPosting system
Illustrative: initial duplicate checks and repeat-safe posting protect different boundaries; enrichment and rule processing are omitted from this scene.

Why this design

  1. Process posting through events

    Chosen
    Start asynchronous processing from the stream of saved authorisations.
    Because
    Separate stages can progress without holding a synchronous request open through the entire posting journey.
    Cost
    The application must track intermediate states and distinguish approval from completed posting.
    Reconsider when
    Use a simpler synchronous design when transaction volume and downstream behaviour make it sufficient.

  2. Design explicitly for retries

    Chosen
    Combine pipe-level duplicate checking with idempotent processing at business boundaries.
    Because
    Repeated delivery must not become a repeated financial effect.
    Cost
    Idempotency state, failure handling and reconciliation add implementation and operational work.
    Reconsider when
    Remove a duplicate-checking layer only when an equivalent guarantee is demonstrated at the relevant business boundary.

  3. Buffer before the posting system

    Chosen
    Place SQS between event routing and the posting consumer.
    Because
    The queue absorbs bursts that could otherwise overwhelm downstream posting.
    Cost
    Queued work adds waiting time and requires backlog monitoring and recovery procedures.
    Reconsider when
    Use direct invocation only when downstream capacity and failure behaviour safely support it.

Cost and operating assumptions

  • Saved authorisations and routing

    DynamoDB writes and storage combine with EventBridge Pipes and bus usage as authorisations become staged events.

  • Function execution

    Deduplication, enrichment and posting incur Lambda request and duration charges, with retries adding further execution.

  • Business rule workflows

    Step Functions orchestration costs depend on the workflow type and execution pattern, including the transitions used by the rules engine.

  • Posting buffer

    SQS request volume follows message delivery, processing and retries, while backlog handling can also increase consumer work.

Assumptions behind the numbers

The supplied guidance provides no monthly total; pricing depends on usage, region and options, including event fan-out, workflow structure, function duration and retry frequency.

How it stays reliable

  • Make repeated work safe

    The guidance uses Lambda idempotency with Powertools; the application must define stable transaction identity and protect downstream business effects.

  • Isolate failed requests

    Route failed requests to the configured SQS dead-letter queue and establish investigation and replay procedures before returning them to processing.

  • Control posting pressure

    Set consumer throughput to suit downstream capacity and monitor queue age and backlog so the buffer does not hide stalled payments.

  • Trace the whole journey

    Use CloudWatch, X-Ray and CloudTrail with application correlation identifiers to connect authorisation, enrichment, rule evaluation and posting outcomes.

When this is a poor fit. A poor fit for a low-volume posting workflow where asynchronous states and reconciliation add more complexity than the scaling benefit warrants.

Full technical detailThe numbered AWS flow, every service and the Well-Architected notes.

How the AWS guidance describes it

  1. Authorisation application and DynamoDB. A user initiates a payment, and the authorisation application approves it and persists the approved authorisation in DynamoDB.
  2. Amazon EventBridge Pipes. A pipe reads approved authorisation records from the DynamoDB table stream and publishes events to a custom EventBridge bus.
  3. AWS Lambda. A deduplication function can be added to the pipe to check for duplicate work before publication.
  4. Amazon EventBridge and AWS Lambda. A bus rule invokes an enrichment function for matching events to add account and bank context.
  5. AWS Lambda and Amazon EventBridge. The enrichment function queries metadata and publishes a new event containing the additional information to the custom bus.
  6. AWS Step Functions. A rule watching for enriched events invokes a workflow that applies business rules as a rules engine.
  7. AWS Step Functions and Amazon EventBridge. When an event passes the business rules, the workflow publishes a new event to the custom bus.
  8. Amazon SQS. A bus rule sends a message to SQS to buffer work and avoid overrunning the downstream posting subsystem.
  9. AWS Lambda and posting subsystem. A Lambda function reads queued messages and invokes the downstream subsystem to post each transaction.
  10. AWS Lambda and Amazon EventBridge. The posting function publishes the final event back to the custom bus.

Well-Architected

Operational Excellence
CloudFormation defines infrastructure, while X-Ray, CloudWatch and CloudTrail support tracing, monitoring and auditing.
Security
Least-privilege policies, KMS encryption and Secrets Manager protect service access, stored data and credentials.
Reliability
Regional services, idempotent processing and dead-letter handling support recovery from repeated delivery and processing failures.
Performance Efficiency
Asynchronous Lambda execution, workflow timeout handling and DynamoDB on-demand capacity accommodate changing request volumes.
Cost Optimisation
Usage-based services, EventBridge Pipes and suitable Graviton2 Lambda workloads reduce unnecessary provisioning costs.
Sustainability
Elastic services, Graviton2 and direct Step Functions integrations reduce avoidable resource use.