Question: different microservices are connecting to single hazelcast cluster because of that if cache is corrupted due to any of them whole cluster is needed to be restarted which affects other services , Is there anyway to prevent this ?

Answer: 
If you have multiple instances of multiple services, then you could set them up to use different storage containers in the cluster.

Ie.

* Instance 1 of service A uses [IMap](https://docs.hazelcast.org/docs/4.0.2/javadoc/com/hazelcast/map/IMap.html) named "A"
* Instance 2 of service A uses [IMap](https://docs.hazelcast.org/docs/4.0.2/javadoc/com/hazelcast/map/IMap.html) named "A"
* Instance 1 of service B uses [IMap](https://docs.hazelcast.org/docs/4.0.2/javadoc/com/hazelcast/map/IMap.html) named "B"
* Instance 2 of service B uses [IMap](https://docs.hazelcast.org/docs/4.0.2/javadoc/com/hazelcast/map/IMap.html) named "B"

So, data isolation. Each service has it's own data storage.

Service 1 instances use map "*A*", and if somehow they corrupt it, service B using map "*B*" is unaffected.

You can then do `hazelcast.getMap("A").clear()` to delete all the data for service A, without affecting service B. Or a selective delete if you can identify the bad records.

For added strength, the (commercial) security module adds role-based authorisation. You could set it up so service A cannot access service B's data (for read or read/write), and that way service A cannot corrupt servier B's data.
If your microservice primarily performs READ operations against the Maps, you could consider using the Near Cache feature.

<https://docs.hazelcast.org/docs/4.0.2/manual/html-single/index.html#near-cache>

The near cache will give you two benefits.

1. Data Get on the Map will be a lot faster as it is pulling from the local memory of your client, if the data for a key is mutated on the cluster the local near cache is invalidated.
2. If the Cluster goes down for some reason the client will continue to grab data from the local memory. To ensure the client keeps responding to near cache gets even if the cluster is down you'll need to configure ASYNC mode on the client connections as per here... <https://docs.hazelcast.org/docs/latest-dev/manual/html-single/index.html#non-stop-client>

Aside from this, I would consider changing your access pattern for the cluster and if possible try to aim for having a cluster per microservice to provide true isolation.

It's often called "Database per Service"...
<https://microservices.io/patterns/data/database-per-service.html>

It's one of the reasons Hazelcast is so popular for Microservices, it's a lot simpler to spin up lots of clusters per microservice than it is for Databases or NoSQL.