GitHub user lhotari added a comment to the discussion: Guaranteeing reply delivery to the same instance in KeyShared subscription without per-instance topics
> I’m trying to implement a request/response pattern between two programs using > Pulsar, but I want to avoid: In the first place, I would avoid request-response over Pulsar since it could lead to a very tightly coupled solution between the applications. For tightly coupled applications, it might be better to use plain HTTP or gRPC interfaces to reduce unnecessary complexity. What is the exact requirement to use request-response over Pulsar? For a RPC use case over Pulsar, there's an example at https://github.com/streamnative/pulsar-recipes/tree/main/rpc . That has a different type of design and relies on consuming rpc client topics using a regex topic pattern. > Creating a large number of per-instance topics or subscriptions Why do you want to avoid this? Pulsar supports a large number of topic and subscriptions. Pulsar features such as namespace policies for TTL and automatically deleting inactive topics could address the possible concerns around maintenance. > Duplicating messages to all instances What is the reason for avoiding duplication? Are the messages large? Just thinking that data pipelines usually do a lot of duplication with intermediate topics where messages could be transformed and/or routed. This simplifies solutions in many cases. > Auto-split or sticky hash range policy is used Auto-split wouldn't provide a guarantee that you are looking for. You'd need to use sticky with Key_shared. An alternative for key_shared subscriptions could be partitioned topics using exclusive or failover subscriptions (there's answers in #24044 about that). GitHub link: https://github.com/apache/pulsar/discussions/24616#discussioncomment-14209164 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
