I test payment systems for banks, and most of my time on ISO 20022 projects goes into one question: does the data a customer entered survive every step until it appears, unchanged, on a statement? A schema-valid pacs.008 is where that work starts, not where it ends. This article sets out the test strategy we use for structured payment messages, in three layers: schema checks, round-trip mapping and reconciliation. The examples use JUnit 5, XMLUnit and Testcontainers. 

ISO 20022 messages are rich and strict, and that is exactly why they are tested badly. The XSD for pacs.008 (FI-to-FI customer credit transfer) allows far more than any real payment scheme accepts. CBPR+, the SEPA rulebooks and the HVPS+ guidelines each add their own rules on top: mandatory fields, maximum lengths, allowed character sets and code lists. A message can pass the XSD and still be rejected by the scheme, or worse, be accepted with data silently cut short. 

The mapping is where the risk sits. Most bank systems don't produce ISO 20022 natively. They map from an internal payment model, from MT103 legacy flows or from a core banking format. Every mapping step can truncate, reformat or drop a field. Since the end of the MT/MX coexistence period for cross-border payments, those losses are no longer hidden behind a legacy format; they show up as rejections, compliance gaps or reconciliation breaks. 

So we test in three layers, each catching a different class of defect. 

Layer 1: schema and usage-guideline checks 

The first layer is fast and runs on every build. Every message the mapper produces, across a scenario matrix of payment types, currencies, charge codes and party structures, is validated against the exact XSD version the scheme uses: 

    static void loadSchema() throws SAXException { 

        schema = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI) 

            .newSchema(Pacs008SchemaTest.class.getResource("/xsd/pacs.008.001.08.xsd")); 

    @MethodSource("com.oceanobe.payments.Scenarios#sepaCreditTransfers") 

    void generatedMessageIsSchemaValid(Payment payment) { 

        String xml = pacs008Mapper.toXml(payment); 

            schema.newValidator().validate(new StreamSource(new StringReader(xml)))); 

The XSD alone doesn't encode the scheme's usage guidelines, so we add explicit rule tests next to it. These are the ones that catch real defects: 

Character sets. SEPA traditionally restricts content to a basic Latin character set. A debtor named Ștefănescu needs a defined conversion rule, and the test should assert the exact output, not just that "something valid" was sent. 

Length limits, for example unstructured remittance information (RmtInf/Ustrd) capped at 140 characters. 

Structured addresses. CBPR+ is moving away from fully unstructured postal addresses. Mappers that still put a whole address into AdrLine need tests that fail before the scheme rejects the message. 

void remittanceOver140CharactersIsRejectedNotTruncated() { 

    Payment payment = aSepaPayment().withRemittance("X".repeat(141)).build(); 

    assertThatThrownBy(() -> pacs008Mapper.toXml(payment)) 

        .isInstanceOf(MappingRuleViolation.class) 

        .hasMessageContaining("RmtInf/Ustrd"); 

Whether the right behaviour is to reject or to truncate with a warning is a business decision, not a testing one. What matters is that the test makes the decision explicit and visible. This is where we pair with the business analyst: each usage-guideline rule becomes an acceptance criterion and then a test. 

Schema checks prove the structure. Round-trip tests prove the meaning. We run two kinds. 

Golden-file comparison. For each key scenario, a reviewed reference pacs.008 is stored in the repository. The generated message is compared to it with XMLUnit, ignoring fields that are expected to change on every run: 

        .compare(Input.fromStream(resource("/golden/pacs008_sepa_basic.xml"))) 

        .withTest(Input.fromString(pacs008Mapper.toXml(goldenPayment()))) 

        .withNodeFilter(n -> !Set.of("MsgId", "CreDtTm", "UETR").contains(n.getLocalName())) 

    assertFalse(diff.hasDifferences(), diff.toString()); 

Golden files double as documentation. When a scheme publishes a new usage guideline version, the diff in the pull request shows reviewers exactly what changed in the output. 

Domain round-trip. Map from the internal model to XML, parse the XML back, and compare the result with the original: 

Payment parsed = pacs008Parser.parse(pacs008Mapper.toXml(original)); 

assertThat(parsed).usingRecursiveComparison().isEqualTo(original); 

Any field that doesn't survive the round trip is either a mapping defect or a known, documented loss. Both outcomes are useful. We feed this test with generated data (long names, diacritics, maximum-length references, amounts at the precision limit, currencies with zero or three decimal places), because hand-written fixtures rarely cover those edge cases. 

The final layer tests what the bank's customers and finance teams actually see. A payment sent as pacs.008 has to show up in the camt.053 end-of-day statement, and the statement itself has to be internally consistent. 

Statement invariants. These can be checked on any camt.053, including files received from other banks. The most important one is that the opening booked balance plus the signed sum of entries equals the closing booked balance: 

    Statement stmt = camt053Parser.parse(resource("/camt053/2026-10-01.xml")); 

    BigDecimal movement = stmt.entries().stream() 

        .map(e -> e.creditDebit() == CRDT ? e.amount() : e.amount().negate()) 

        .reduce(BigDecimal.ZERO, BigDecimal::add); 

    assertThat(stmt.openingBooked().add(movement)) 

        .isEqualByComparingTo(stmt.closingBooked()); 

Two details catch out many parsers. First, balances carry their sign in CdtDbtInd, not in the amount, so an overdrawn opening balance must be negated. Second, amounts are always BigDecimal, never double. 

End-to-end matching. With Testcontainers we run the real path in one test: a payment command published to Kafka, the payment service producing pacs.008, a clearing simulator answering with pacs.002, and the statement service generating camt.053. The test then finds the entry by EndToEndId and checks it field by field: 

assertThat(statement.entryFor(payment.endToEndId())).hasValueSatisfying(entry -> { 

    assertThat(entry.amount()).isEqualByComparingTo(payment.amount()); 

    assertThat(entry.currency()).isEqualTo(payment.currency()); 

    assertThat(entry.creditDebit()).isEqualTo(DBIT); 

    assertThat(entry.remittanceInfo()).isEqualTo(payment.remittanceInfo()); 

The same test runs for rejection paths. A pacs.002 with status RJCT must result in no booked debit, or in a debit and a matching return, depending on the scheme. Here too, the rule should be written down before the test is. We drive the clearing simulator with real ISO external reason codes, such as AC01 (incorrect account number), AM04 (insufficient funds) and RR04 (regulatory reason). Each code then maps to a customer-facing message and a status in the channel, and those mappings are tested too. 

Most of the value of this strategy comes from choosing the right scenarios. Here is an excerpt of the kind of matrix we keep: 

Scenario | Scheme | Edge case | Expected outcome 

Domestic SEPA credit transfer | SEPA SCT | Debtor name with Romanian diacritics | Converted per agreed rule, golden file matches 

Cross-border EUR → USD | CBPR+ |Fully unstructured creditor address |Rejected by mapper before sending 

Salary batch, 5,000 payments | SEPA SCT |Mixed valid and invalid IBANs | Valid items booked, invalid ones reported individually 

JPY payment | CBPR+ |Zero-decimal currency |Amount has no fractional part in pacs.008 and camt.053 

Rejected payment | SEPA SCT |pacs.002 RJCT, reason AC01 |No booked debit, customer sees "incorrect account"

Each row is cheap to add and maps directly to a test in one of the three layers. 

Testing ISO 20022 Message Flows  

A practical test strategy for structured payment messages: schema checks, round-trip mapping and reconciliation checks.

A test strategy for ISO 20022 payments: schema and usage-guideline checks, round-trip mapping and camt.053 reconciliation, with JUnit 5 and XMLUnit. 

Validating pacs.008 and camt.053 Mappings End-to-end 

After years building and maintaining Java payment services for banks: payment initiation, routing to clearing systems, and the calls to fraud, sanctions and limits services that each payment waits on. Virtual threads come up in almost every architecture discussion now, usually with the question "should we just turn them on?" With Java 25 LTS and Spring Boot 4, my answer is mostly yes, but the platform team should know exactly which bottlenecks this removes and which ones it only moves somewhere else. 

A typical Spring Boot payment API spends most of its time waiting. It waits on the database, on the core banking system, on the fraud scoring provider, on sanctions screening and on the payment scheme gateway. With classic platform threads, every waiting request holds an operating-system thread, so throughput is capped by the size of the Tomcat thread pool (200 by default) long before the CPU is busy. 

Virtual threads (final since JDK 21, JEP 444) are lightweight threads managed by the JVM. When one blocks on I/O, the JVM unmounts it from its carrier thread and runs another one in its place. Blocking code stays blocking and readable, but waiting no longer costs an OS thread. 

In Spring Boot 4, enabling them is one property: 

With that property set, Tomcat request handling, @Async methods and Spring's task executors run on virtual threads. The business code doesn't change. 

The biggest gains appear in the parts of the system that are I/O-bound and use a thread per request: 

Payment orchestration endpoints that call four or five downstream services in sequence. Each call that waits no longer occupies a scarce platform thread. 

Fan-out checks. Running sanctions, fraud and limits checks in parallel becomes simple, readable code: 

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) { 

    Future<SanctionsResult> sanctions = executor.submit(() -> sanctionsClient.screen(payment)); 

    Future<FraudScore>      fraud     = executor.submit(() -> fraudClient.score(payment)); 

    Future<AccountLimits>   limits    = executor.submit(() -> limitsClient.fetch(payment.debtorAccount())); 

    return decisionEngine.decide(sanctions.get(), fraud.get(), limits.get()); 

Traffic peaks such as salary days, end-of-month batches and retail events. These no longer cause request-thread exhaustion, which used to show up as rising latency across every endpoint, including the ones unrelated to the load. 

The less visible benefit is about the codebase. Many banks introduced reactive stacks such as WebFlux mainly to work around thread limits. For new I/O-heavy services, virtual threads deliver much of that scalability with plain imperative code that is easier to review, debug and staff for. 

What Java 25 fixed: synchronized no longer pins 

On Java 21, the main caveat was pinning. A virtual thread that blocked inside a synchronized block stayed attached to its carrier thread. With only as many carriers as CPU cores, a few pinned threads waiting on a slow downstream call could stall the whole service. This mattered in practice, because JDBC drivers, connection pools and older client libraries used synchronized widely. 

JEP 491, delivered in JDK 24 and therefore part of Java 25 LTS, removes this limitation. Virtual threads can now block inside synchronized methods and blocks, and in Object.wait(), without holding their carrier. For teams on Java 25, the advice to rewrite every synchronized as a ReentrantLock no longer applies. 

Pinning is now rare, but it hasn't disappeared. The cases that remain: 

Native code. A virtual thread that calls a native method through JNI, or through the Foreign Function & Memory API, stays pinned for the duration of the native call. In banking this is not an edge case: HSM client libraries and PKCS#11 providers used for PIN translation, MAC generation and payment signing are often native. A slow HSM round-trip pins a carrier. 

Class initialisation. Blocking inside a static initialiser, or waiting for another thread to finish initialising a class, still pins. 

Both cases are easy to find before production. JDK Flight Recorder records a jdk.VirtualThreadPinned event: 

java -XX:StartFlightRecording:settings=profile,filename=payments.jfr -jar payment-api.jar 

jfr print --events jdk.VirtualThreadPinned payments.jfr 

Run this during a load test that includes the signing and HSM paths. For confirmed native hot spots, the usual fix is to send those calls to a small, bounded pool of platform threads, which keeps carrier threads free for everything else. 

Virtual threads remove the thread bottleneck. They do not remove any other bottleneck, and in a payment service the others are what matter most. 

Your connection pool is now the limit. With 200 platform threads, a HikariCP pool of 40 connections rarely saw more than 200 requests waiting for it. With virtual threads, ten thousand concurrent requests can queue for those same 40 connections. Keep maximum-pool-size sized to what the database can actually handle, and set a short connection-timeout so overload fails fast rather than turning into long latency. 

Downstream services still have limits. A fraud scoring vendor with a contractual rate limit, or a core banking API sized for a fixed number of concurrent sessions, will not scale because your service can now send more requests. The thread pool used to limit concurrency without anyone noticing. That limit now has to be explicit: 

    private final Semaphore permits = new Semaphore(50); // agreed concurrency with the provider 

    private final RestClient restClient; 

    public FraudScoringClient(RestClient.Builder builder) { 

        this.restClient = builder.baseUrl("https://fraud.internal").build(); 

    public FraudScore score(PaymentRequest payment) { 

            if (!permits.tryAcquire(200, TimeUnit.MILLISECONDS)) { 

                throw new DownstreamSaturatedException("fraud-scoring"); 

        } catch (InterruptedException e) { 

            Thread.currentThread().interrupt(); 

            throw new DownstreamSaturatedException("fraud-scoring"); 

            return restClient.post().uri("/score").body(payment).retrieve().body(FraudScore.class); 

The same principle applies to bulkheads. A Resilience4j semaphore bulkhead fits virtual threads naturally, while a thread-pool bulkhead brings back the platform threads you just removed. 

CPU-bound work gains nothing. Signature verification, ISO 20022 XML parsing and validation, and encryption keep the same throughput, because they need a CPU core, not a thread that can wait. 

Java Virtual Threads in Payment APIs 

Where Project Loom's virtual threads actually help a Spring Boot payment service, where thread-pinning still bites, and what to leave alone.

Where Java 25 virtual threads help Spring Boot payment APIs, where pinning still bites (HSMs, JNI) and why connection pools and rate limits matter more. 

What Changes and What Doesn't 

I've spent most of my career building Angular frontends for banks, and the hardest screens are always the live ones: treasury dashboards, corporate account overviews and payment monitors where a balance changes while the user is looking at it. When we plan a move to Signals on screens like these, the API is the easy part. What takes the work is migrating without a single stale or out-of-order balance reaching the screen. This article walks through how we approach that migration in practice, for an Angular frontend fed by Server-Sent Events from a Kafka-backed balance service. 

Why live balances are harder than most Signals tutorials assume 

Most Signals examples show a counter, a form or a filtered list. A banking dashboard has three properties those examples don't: 

Ordering matters. Two balance updates for the same account can reach the browser out of order after a reconnect. Showing the older one last is a real defect. 

Bursts are normal. End-of-day batch postings, card settlement files and sweeps can produce hundreds of updates per second for one corporate client. 

Every number is money. Floating-point arithmetic, rounding in the view layer and silent truncation are not acceptable anywhere in the pipeline. 

None of these are problems with Signals. But a migration that swaps async pipes for toSignal() one line at a time can expose all three at once. The approach below keeps the RxJS transport layer where it adds value, moves state into signals, and removes Zone.js only at the end. 

Kafka (balance-events topic, keyed by accountId) 

   → Spring Boot service (consumer + per-customer fan-out) 

   → SSE endpoint  /api/stream/balances 

   → Angular: RxJS at the edge → signal-based store → OnPush components 

Two backend decisions make the frontend migration much simpler, so it is worth agreeing on them with the Java team first. 

Every event has a monotonic version per account. This can be a ledger sequence number or a balance version from the core system. It cannot be the browser's arrival time. 

The SSE id field carries that version, so the browser's built-in reconnect sends Last-Event-ID and the server can resume from the right point: 

@GetMapping(path = "/api/stream/balances", produces = MediaType.TEXT_EVENT_STREAM_VALUE) 

public Flux<ServerSentEvent<BalanceEvent>> balances( 

        @AuthenticationPrincipal Jwt jwt, 

        @RequestHeader(value = "Last-Event-ID", required = false) String lastEventId) { 

    Flux<ServerSentEvent<BalanceEvent>> events = balanceFeed 

        .forCustomer(jwt.getSubject(), lastEventId) 

        .map(evt -> ServerSentEvent.<BalanceEvent>builder() 

            .id(evt.accountId() + ":" + evt.version()) 

    Flux<ServerSentEvent<BalanceEvent>> heartbeat = Flux.interval(Duration.ofSeconds(15)) 

        .map(i -> ServerSentEvent.<BalanceEvent>builder().comment("keep-alive").build()); 

    return Flux.merge(events, heartbeat); 

The heartbeat is a comment line. The browser ignores it, but it stops load balancers and corporate proxies from closing an idle connection. One more banking-specific detail: the native EventSource cannot send an Authorization header. Use same-site session cookies with withCredentials, or use a fetch-based SSE client if your security model requires bearer tokens in the browser. 

This distinction drives every decision in the migration. 

A signal holds a current value. When it changes several times before Angular renders, consumers see only the latest value, which is exactly what you want for "the available balance of account X". An observable delivers every event over time, with operators for timing, retrying, cancelling and combining. 

SSE connection, reconnect with backoff, burst batching  | RxJS 

Cancelling in-flight requests when the user switches context (switchMap) | RxJS 

Current balance per account, connection status, selected account | Signals 

Totals, filtered views, "is this tile stale?" | computed() 

Transaction feed (events you must not drop) | RxJS scan → toSignal() 

Teams that try to make everything a signal usually end up rebuilding retry, debounceTime and switchMap badly with effect(). Teams that keep everything in RxJS miss out on fine-grained change detection. The migration moves the boundary; it does not remove one side. 

Step 1: make OnPush universal before touching Signals 

Before converting any state, switch every component on the dashboard to ChangeDetectionStrategy.OnPush and fix what breaks. This step gives you three things: 

It surfaces components that mutate inputs in place or rely on Zone.js to pick up changes made in callbacks. Those components would break silently later, after Zone.js is removed. 

It forms a stable baseline you can profile against. 

It is a low-risk change you can release on its own. 

At the same time, make an inventory of every subscribe() call, async pipe and BehaviorSubject in the dashboard's feature area. Mark each one as either state (a current value) or event stream (each emission matters). That list becomes your migration backlog. 

Step 2: bridge at the service boundary, not in components 

Don't change the transport. Wrap EventSource in an observable once, keep all the stream logic in RxJS, and expose signals from the service. Components never see an observable. 

  version: number;          // monotonic per account, from the ledger 

  availableMinor: string;   // minor units as a string, e.g. "1250075" = 12,500.75 

export function fromEventSource<T>(url: string, eventName: string): Observable<T> { 

  return new Observable<T>(subscriber => { 

    const source = new EventSource(url, { withCredentials: true }); 

    const onEvent = (e: MessageEvent) => subscriber.next(JSON.parse(e.data) as T); 

    source.addEventListener(eventName, onEvent); 

      // EventSource retries on its own; we only fail when it gives up. 

      if (source.readyState === EventSource.CLOSED) { 

        subscriber.error(new Error('Balance stream closed')); 

type ConnectionState = 'connecting' | 'live' | 'reconnecting'; 

  private readonly http = inject(HttpClient); 

  private readonly destroyRef = inject(DestroyRef); 

  private readonly _balances = signal<ReadonlyMap<string, BalanceEvent>>(new Map()); 

  private readonly _connection = signal<ConnectionState>('connecting'); 

  readonly balances = this._balances.asReadonly(); 

Angular Signals in real-time banking dashboards 

How to move step by step in apps with heavy transaction streams, covering change detection, zone-less rendering and where RxJS still makes sense.

Migrate an Angular banking dashboard from RxJS to Signals: SSE from Kafka, ordered live balances, zoneless change detection and where RxJS still fits.

Migrating from RxJS without breaking live balances 

A green @EmbeddedKafka test suite is one of the more convincing false negatives I test against. It runs fast, it passes reliably, and the bug it didn't catch — a consumer that silently double-processes a batch of transactions the moment a second pod joins the consumer group — showed up in production during a routine scaling event, not a chaos experiment. This is about why that gap exists and which tests actually close it. 

What an embedded broker actually is, and why "passing" doesn't mean what it looks like 

@EmbeddedKafka from spring-kafka-test runs a real Kafka broker process, in-memory, inside your test JVM. That's genuinely useful for a specific, narrow purpose: proving your @KafkaListener is wired correctly, your serializer doesn't throw on your actual message shape, and your Spring configuration boots without error. It's fast, and it's honest about what it's testing. 

What it isn't is a reliable proxy for how your consumer behaves during a rebalance — and this isn't a vague "integration tests are always weaker than production" caveat, it's a specific, documented limitation. Spring Kafka's own test support disables Kafka's KRaft mode by default in @EmbeddedKafka, explicitly because of instabilities observed running the newer consumer group protocol (KIP-848) under it — and that new protocol, the one an increasing share of production clusters are moving toward, is only fully testable against a real cluster, not the lightweight broker @EmbeddedKafka builds internally. If your production brokers run KRaft with the new group coordinator and your test suite runs an embedded broker that's quietly falling back to the classic protocol, your rebalance tests are passing against a coordination mechanism your production traffic doesn't actually use. 

Rebalance-triggered duplicate processing is the specific failure worth designing a test around: a consumer is mid-batch when a rebalance strips its partition assignment away — a second instance scaled up, a pod restarted, a deploy rolled — and if the offset for that batch wasn't committed before the partition was revoked, the newly-assigned consumer picks up from the last committed offset and reprocesses records the first consumer already handled. On a payment or transaction pipeline, "reprocessed" isn't a log noise problem — it's the exact duplicate-processing scenario idempotency keys exist to catch downstream, and a test suite that never actually triggers a real rebalance will never exercise that path at all. 

class ConsumerRebalanceIntegrationTest { 

    static KafkaContainer kafka = new KafkaContainer(DockerImageName.parse("apache/kafka:3.8.0")); 

    void reassignedPartitionResumesFromLastCommittedOffset() throws Exception { 

        String topic = "tx-events-" + UUID.randomUUID(); // unique per test — no shared state 

        String groupId = "settlement-test-" + UUID.randomUUID(); 

        try (KafkaProducer<String, String> producer = producer(kafka.getBootstrapServers())) { 

            produceRecords(producer, topic, 100); 

            try (KafkaConsumer<String, String> consumerA = consumer(kafka.getBootstrapServers(), groupId)) { 

                consumerA.subscribe(List.of(topic)); 

                ConsumerRecords<String, String> firstBatch = consumerA.poll(Duration.ofSeconds(5)); 

                // deliberately do NOT commit — simulates a crash mid-batch 

                try (KafkaConsumer<String, String> consumerB = consumer(kafka.getBootstrapServers(), groupId)) { 

                    consumerB.subscribe(List.of(topic)); 

                    // joining triggers a real rebalance against a real group coordinator 

                    ConsumerRecords<String, String> resumed = pollUntil(consumerB, 

                        records -> !records.isEmpty(), Duration.ofSeconds(15)); 

                    assertThat(resumed.count()).isEqualTo(firstBatch.count()); // full re-delivery, not partial 

 The assertion worth writing here isn't "a rebalance happened" — that's an implementation detail, not an outcome. It's an invariant: every record from the uncommitted batch gets redelivered exactly once to whichever consumer ends up owning that partition, with none silently dropped and none double-delivered to two active consumers at once. That invariant is what your idempotency-key handling downstream is actually built to tolerate — this test is what proves the tolerance is being exercised, not just theorized about. 

What Testcontainers gets you that a mock or an embedded broker can't 

The reason this test is trustworthy where a mocked Consumer or an embedded broker's simulated coordination wouldn't be: KafkaContainer runs an actual Kafka broker process in Docker, with a real group coordinator, real heartbeats, and real partition-assignment protocol exchange between consumer instances. When consumerB.subscribe() triggers a rebalance in the test above, that's the same coordination machinery — JoinGroup, SyncGroup, partition revocation and reassignment — that runs in production, not a simulated approximation of it. That's what makes the test capable of catching a bug in your offset-commit timing relative to partition revocation, which is precisely the class of bug an in-process embedded broker's simplified coordination model is the least likely to reproduce faithfully. 

Worth being honest about, so the test suite doesn't overclaim what it covers: a single KafkaContainer is a real broker, but it's still one broker, not a cluster. It won't reproduce leader movement across brokers, rack-awareness behavior, a rolling broker upgrade, or a group coordinator failing over after a node loss — those need a genuinely multi-broker Testcontainers setup, which is heavier, slower, and worth reserving for the specific tests that need exactly that failure mode, not the default for every consumer test in the suite. 

Test hygiene matters more here than in most integration testing, because Kafka's coordination is asynchronous and stateful by nature: a unique topic and consumer group ID per test avoids one test's leftover group state leaking into another's assertions, and waiting on an observable condition with an explicit deadline — as in pollUntil above — is what keeps these tests deterministic; a fixed Thread.sleep() guessing how long a rebalance takes is exactly the kind of flaky-test debt that makes a team stop trusting the suite and start skipping it under deadline pressure. 

The right shape for a Kafka test suite isn't "replace embedded tests with Testcontainers everywhere" — that's slower for no benefit on the tests that were never exercising coordination behavior in the first place. Unit tests with a mocked Consumer/Producer cover business logic in isolation, fast, and should be the majority of the suite. @EmbeddedKafka earns its place for exactly what it's good at: confirming Spring wiring and serialization work, quickly, in CI. Testcontainers earns its place specifically for the tests that exist to prove something about Kafka's own coordination behavior — rebalance handling, offset-commit timing, consumer-group recovery — because that's the one category of bug where a lighter-weight substitute isn't just faster, it's testing a different, friendlier system than the one actually running in production. 

Testing Kafka Consumers 

Where embedded-broker tests give false confidence, and the Testcontainers patterns that catch real consumer-group rebalancing and offset-commit bugs.

A green EmbeddedKafka suite is a convincing false negative. Here's the rebalance bug it can't catch, and the Testcontainers pattern that actually does.

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!