Sending the same event from several microservices through Kafka

kafka

(Alexandr) #1

Hello everyone.
If I have services A , B , C and I want services A and B to send absolutely identical event MyEvent to the service C through Kafka - then 1) in api of which service should I place the MyEvent class - A , B or C ? 2) do I have to subscribe in the service C to topics of A and B simultaneously in order to listen the same MyEvent event or I can somehow make A and B to publish this event to the same topic?


(Alan Klikic) #2

@reactivemaster

You have these options:

  1. topic per publishing service
    a) topic and message definition in each API
    - service A and B API describes each topic definition and message definition
    - service C subscribes to topic A and B

    PROS: each API is decoupled from another. “By the book”
    CONS: redundant maintaining of message definition, separate consuming on service C

    b) topic definition in each API, topic message definition in shared “protocol” project
    - separate “protocol” project describes message definition
    - service A and B API describes each topic definition and uses message definition from “protocol” project dependency
    - service C subscribes to topic A and topic B
    PROS: NO redundant maintaining of message definitons
    CONS: APIs are coupled by the same protocol, separate consuming on service C

  2. one topic
    a) topic and message definition in one API
    - services A and B implement the same API
    - this can be used only if services A and B, by sevice descriptor, only define topic descriptor
    - if services A and B expose also service calls then this will not work because services are located based on service name in API descriptor)
    - service C subscribes to one API

    PROS: consuming one topic on service C, NO redundant maintaining of message definitons
    CONS: can be used only in specific cases, services are coupled with the same API

    b) topic definition in each API, topic message definition in shared “protocol” project

    • separate “protocol” project describes event definition
    • service A and B API describes each topic definition (WITH THE SAME TOPIC NAME) and uses message definition from “protocol” project dependency
    • service C can subscribe to service A or service B because both publish to the same topic

    PROS: consuming one topic on service C, NO redundant maintaining of message definitions
    CONS: APIs are coupled by same protocol and topic, consuming of one topic has to be done by subscribing to service A or service B (messy)

Hope this helps.

Br,
Alan