Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how the gateway forwards a client request to a broker #560

Closed
McAlm opened this issue Jan 13, 2022 · 2 comments
Closed

Document how the gateway forwards a client request to a broker #560

McAlm opened this issue Jan 13, 2022 · 2 comments

Comments

@McAlm
Copy link

McAlm commented Jan 13, 2022

for jobs and process instances the technical identifier, e.g. process instance key, contains the partition id, therefore the gateway can decode the partition id and reach the correct broker.
For publish message commands the gateway calculate a hash of the correlation key to identify the correct partition to send the message to and in the same way the workflow engine does calculate the hash of the correlation key of messages it awaits find the right partition to correlate the message on.

@akeller
Copy link
Member

akeller commented Mar 16, 2022

@korthout this feels like a topic you might be able to help with. Can you take a look? Or help me find someone who can?

@korthout
Copy link
Member

IMO these technical details are not suitable for public documentation. Forwarding requests happens transparently to reduce complexity for the user. The user does not have to know how this works, as long as they can trust that the dedicated Zeebe gateway can reliably forward requests to the correct broker. If we were to document it, we would bind ourselves to that particular implementation. We should avoid that to stay flexible.

I'll close this now, but I'd be happy to hear counterarguments. Please re-open the issue if you believe we should document this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants