I think we've covered this previously Ankit Prabhu . As bucket/collection creation proceeds asynchronously through the cluster, there is no way to really know if it should exist and doesn't exist yet or does not exist.
Because of that limitation, SDKs retry until timeout in order to address the UX behind the scenario where they use the management API to create a bucket or collection, then immediately try to access it. That was an intentional design decision. There were only two options given the interface from the cluster, one being retry until timeout, the other being fail to allow the bucket or collection to be accessed.
There is a plan to make this better in a future release. See MB-46643 which is about collections and MB-111484.
libcouchbase does have retry strategies which were discussed with the eventing team before. If you want to handle these at a higher level, you can. libcouchbase is working as intended here.