Confusion with AksSamples/teams-recording-bot

Describe the issue
This is more of a question than an issue, so apologies, hopefully, I'm not the only one in this position. Having successfully created a solution based on the PolicyRecordingBot Sample, I noticed the AksSamples/teams-recording-bot sample. Having never done Kubernetes before and only a little of Docker, I have a general idea but nothing substantial to completely understand and therefore save myself from confusion. I assume this architecture allows scale up and scale down to provide a more improved ability to cope with a broader scope of potential loads. My confusion is that from looking at the code I can see references to the Azure Event Grid via the IEventPublisher and I have (possibly by mistake) also assumed this is intended to allow the bot instances/pods to communicate state with each other and therefore have a form of redundancy/resiliency?! However, until looking into this sample, I had never heard of the Azure Event Grid, and after a brief investigation, I feel the sample is missing the logic to subscribe/consume to the events being published throughout the code.

Code Snippet
interface IEventPublisher within the IEventGridPublisher.cs
Several references to the publish method of that interface within the BotMediaStream and CallHandler classes

Expected behavior
To see some logic that subscribes/consumes the published events to complete the knowledge gaps on the purpose/intentions of all the events published via the Azure Event Grid. Anyone else noticed this? Am I correct or mistaken? Any assistance is greatly appreciated

Graph SDK (please complete the following information):
Not Applicable, simply consult the sample repo

Call ID
Not Applicable

Logs
Not Applicable

Additional context
Add any other context about the problem here.

Start with the AksSamples/teams-recording-bot sample, especially IEventGridPublisher.cs and the publish calls in BotMediaStream and CallHandler. Trace the referenced Azure Event Grid flow and determine whether subscription or consumption logic is present. Done means the sample’s event purpose and intended architecture are clearly documented, including whether consumers are expected elsewhere.