Purpose of lock store

Is a lock store needed if all conversation IDs are unique for each user? I have multiple Rasa servers running in parallel as replicated services. They all point to the same redis tracker store. The Docs suggest that you use a RedisLockStore if you replicate the Rasa servers. Since all my conversation IDs are unique for each user, it would be unlikely that a second request, for a particular conversation_id, would hit a Rasa server before the first one finished processing. Is it still necessary for me to setup a RedisLockStore?

Lock store docs: Lock Stores

The lock store also makes sure only one rasa server works on a single conversation; conversation IDs should always be unique, but you should still use the lock store for this purpose.

@sjtilney
I have multiple Rasa servers running in parallel as replicated services

Can you please tell me how did u achieve this?

Could you explain this little more. if the conversation IDs are unique for different users, every rasa server will get only one message that is associated with that user at a time right, so what advantage are we getting from the lock store.

I am thinking of a case when the same user types multiple messages continuously and every one of them reaches different rasa servers, Is it here that the lockstore comes into play to maintain the ordering of these messages and avoid any race conditions?

If we assume a stituation where the messages are coming one at a time from the user and next message only comes once the processing of all messages previous messages are completed, do we need a lockstore?

Even when the user sends one message at a time (with bot response following each), it is possible for their message to get to any one of the rasa servers or more than one. See this post When more than one Rasa server Pod is run on kubernetes we don't get intended results - #7 by erohmensing for an example of what can go wrong when a persistent lock store is not used.

thanks for replying, will check the post you shared and get back if I have further doubts.