aws-event-driven-finops-platform

After years operating financial platforms on AWS, the question I saw answered wrong most often was not "which event service should we use?" — it was "what does this cost per month when volume doubles, and who operates it when the queue lags?". Most reference diagrams put EventBridge, SQS, Kinesis and MSK side by side as if they were interchangeable. They are not. Each one has a different billing model, a different ordering guarantee and a different operational cost.

This repository models a fictional bank as an event mesh and uses that scenario to make the differences concrete. The domain is deliberately recognizable: AccountOpened, PixPaymentRequested, TransactionAuthorized, FraudRiskScored, StatementGenerated. Every event has a documented contract, and every routing decision has an ADR explaining why that service and not another.

What it is not: a deployable core banking system. It is a reference for making defensible decisions — the Python code tests the service-selection logic, the documentation records the trade-offs, and the frontend in frontend/ presents all of it at finops.moretes.com. If you need a system to actually process Pix payments, this repository shows how to think; it does not ship the system.

The core of the repository is the decision rule: given an event with expected volume, ordering requirement and retention, which event service is the cheapest one that still meets the requirement? The answer changes per event, which is why the logic lives in Python with tests, not on a slide.

| Service | Use when | Dominant cost | Trade-off |

|---|---|---|---|

| EventBridge | content-based routing across domains, moderate volume, no strict ordering | per event published | higher latency than a direct queue; no cheap native replay |

| SQS | buffer between producer and consumer, retry and DLQ, ordering only per group (FIFO) | per request | FIFO throughput bounded by MessageGroupId |

| Kinesis Data Streams | per-partition ordering, multiple consumers, replay within retention | per shard-hour | a shard is a fixed cost even with no traffic |

| MSK | sustained high volume, an existing Kafka ecosystem, long retention | per broker-hour + storage | a cluster to operate at 2 AM |

The rule that falls out of this: PixPaymentRequested goes through EventBridge because it must reach several domains; TransactionAuthorized goes to Kinesis because per-account order matters and the volume justifies the shard; MSK only enters when sustained volume makes broker-hours cheaper than shards — and never before, because the cost of operating a Kafka cluster does not show up on the invoice, it shows up on the on-call rotation.

pytest -q validates exactly these decisions. Change an event's expected volume and the test tells you whether the chosen service is still the right one.

A banking reference architecture that ignores security and observability is not a reference — it is a drawing. Three decisions in this repository exist so it can be taken seriously by people who work under BACEN, PCI-DSS or LGPD.

Idempotency as the default, not as a patch: every consumer writes an idempotency key to DynamoDB before producing a side effect. In Pix, a redelivered event without that protection becomes a double transfer; in a queue with retry, redelivery is not an exception, it is normal behavior.

End-to-end traceability: X-Ray propagates the trace from PixPaymentRequested to StatementGenerated, through Step Functions. Without it, the 2 AM incident becomes a search across five uncorrelated log groups.

Security in the pipeline, not in review: CodeQL for static analysis, Trivy for vulnerabilities in dependencies and images, Gitleaks for leaked secrets, dependency review and npm audit for the supply chain. The only hard gate is a secret in a commit — the rest informs. The frontend being static and framework-free is not just aesthetics: it shrinks the surface those tools need to watch to a handful of files.

The cost that matters here is the cost of maintaining: every one of those tools produces false positives, breaks on updates and needs someone to read the report. I picked the ones that fit GitHub Actions without their own infrastructure, because a pipeline nobody maintains is worse than none.