Skip to content
Karthik Kodati, home

Case study 02 · Financial services, event-driven architecture

Validating Kafka event streams in financial systems

QA leadership for financial systems built on Kafka event streams, using observability data and automated quality gates to keep releases trustworthy.

Organisation
MphasisClient: JPMorgan Chase
Role
PlaceholderConfirm your role (e.g. QA lead)
Period
PlaceholderAdd engagement dates
Stack
  • Kafka
  • Splunk
  • Dynatrace
  • SonarQube
  • CI/CD

PlaceholderAdd one verified, non-confidential headline outcome

Business problem

In an event-driven financial system, a business transaction is a sequence of messages across services rather than a single request and response.

Quality has to be proven across that sequence, and failures have to be traced to the service and message where they started.

Constraints

  • Financial correctness leaves little room for ambiguous test results.
  • Events are asynchronous, so tests cannot assume ordering or timing.
  • Production-like data is sensitive and cannot be exposed.
  • Diagnosis depends on logs and traces held in observability platforms.

Architectural approach

  • Validate behaviour at the event level: what was published, what was consumed, and what changed as a result.
  • Use Splunk and Dynatrace as test evidence, not only as production monitoring, to shorten debugging.
  • Put automated quality gates in the pipeline so a build carries a clear pass or fail signal.

Architecture

  1. 01 · Producers

    • Upstream services

  2. 02 · Event stream

    • Kafka topics

  3. 03 · Consumers

    • Downstream services

  4. 04 · Validation

    • Event checks
    • State checks

  5. 05 · Signals

    • Splunk
    • Dynatrace
    • Quality gates
Conceptual flow based on the components described. It does not represent any client’s internal architecture.

Framework components

Event-stream validation
Checks on Kafka messages across financial-system workflows.
Observability-backed debugging
Log and trace correlation in Splunk and Dynatrace to locate failures.
Automated quality gates
Pipeline checks, including static analysis with SonarQube, before release.

Key decisions

Treat observability data as test evidence
Asynchronous failures are often only visible in logs and traces, so they belong in the diagnosis loop.
Gate releases automatically
A consistent, automated signal is easier to trust than manual sign-off under time pressure.

Integrations

  • Kafka
  • Splunk
  • Dynatrace
  • SonarQube
  • CI/CD pipeline

Evidence

Asserting on an event without assuming timingIllustrative
import { expect } from "@playwright/test";

// Poll for the expected event instead of sleeping for a fixed time.
await expect
  .poll(async () => consumer.findEvent({ type: "PaymentSettled", correlationId }), {
    timeout: 30_000,
    intervals: [500, 1_000, 2_000],
  })
  .toMatchObject({ status: "SETTLED", amount: expectedAmount });

Synthetic illustration using a generic consumer. Not taken from any client codebase.

PlaceholderUse a generic diagram only. No topic names, service names, or internal architecture.
Generic event-validation flowArchitecture diagram
PlaceholderAdd a sanitized view of gate stages
Quality gate stagesCI/CD pipeline

Outcomes

  • PlaceholderAdd verified outcome: defect detection or escape rate, if shareable
  • PlaceholderAdd verified outcome: time to diagnose failures, if shareable

Lessons learned

  • PlaceholderAdd a lesson learned from validating event-driven systems

Repository and confidentiality

PlaceholderLink a public, synthetic demo if you publish one

No client data, topic names, service names, or internal architecture are shown. The flow is generic.

Next case studyLeading a test automation transformation