Joins & Repartitioning

O fluxo de risco juntou pagamentos e fraude por paymentId, depois enriqueceu o resultado com o merchantId numa KTable e, por fim, juntou a velocidade por userId.

payment.validated --rekey paymentId + repartition--+
                                                   +→ stream-stream join
fraud.signal ----------------paymentId-------------+
payment.fraud.joined --rekey merchantId + repartition → merchant.profile KTable
payment.fraud.joined --rekey userId + repartition     → velocity KTable

Co-partitioning

Um join exige que as chaves correspondentes possam chegar à mesma task/partition. O teste com seis partitions em ambos os tópicos enviou a mesma key para partitions diferentes (left@1, right@4) e não produziu join. Quando a key foi enviada para a mesma partition, o join apareceu. Portanto, contagem igual não garante distribuição compatível; partitioners diferentes ainda quebram a semântica.

Discrepância 6×3

O probe isolado criou copart-left-6 e copart-right-3, ambos RF=3 e min.insync.replicas=2. Com GROUP_PROTOCOL=classic, Kafka Streams 4.3.1 atribuiu as nove source partitions e chegou a RUNNING, sem lançar a exceção 6-versus-3 esperada. Com GROUP_PROTOCOL=streams, o cluster rejeitou o group antes da atribuição com GROUP_ID_NOT_FOUND: Group ... is not a streams group. A falha de startup 6×3, portanto, permanece não comprovada neste cluster/runtime; não é apresentada como facto.

Tópicos internos

O join direto não criou repartition topic porque não houve alteração de key. Criou apenas changelogs explicitamente nomeados para as window stores. Na topologia de risco, os rekeys intencionais criaram os repartition topics correspondentes; não foram confundidos com changelogs.