Yes the general pattern here is you have a function or some other API that gets the request and then pops it into Event Hubs. There’s also a pattern where you give each publisher a “send only” secured access signature token so they can push directly to Event Hubs but not read any messages — but based on the above sounds like you don’t want them to…
Yes but the app setting today points to a specific version of the secret anyway. So if you update the secret you’ll have to update the version in the app setting string which will trigger a restart / refresh automatically anyway.
Yes we will only fetch the secret during an app instantiation. I’d expect the “fetch once and re-use from cache” behavior will protect you from key vault throttles.
Not sure I understand but this would work for consumption. Whether you are auto scaled to 1 instance or 200, partitions will still be honored and order preserved. Just variability in total throughout based on how much it scales. So even for sparse or bursty workloads in consumption this would work.
Make sure you have:
Just update the application setting with the current version after setting a new secret. Once you update the app setting the application will reload the specified version
Yes that is strange as just the default code in GitHub *should* show the issue of checkpoints not progressing until the entire batch is complete (a behavior that Service Bus and Queues aren’t victim of). So can’t do much to explain discrepancy. Just make sure you are starting them all at the same time (I pushed the queue and event hub while the apps…
Interesting. Not sure. My code is all on GitHub — including the code I used to publish. It may be if you set event hubs to process messages in parallel per partition you may get better perf for smaller workloads. Generally we recommend to batch receive though as it scales better for larger workloads and preserves order.