Hello @Kasun_Magedaragama 
,
and welcome to the community. We’re glad to have you join us and we look forward to your contributions.
An even number of voting members is always a bad choice for elections. You generally add a cheap (non dataholding) arbiter to archive an odd number of voting members - you can look at an arbiter as an tie-breaker. The MongoDB Documentation provides further detail
–
Beside this you should also keep the MongoDB write concern in mind.
write concernallows your applications to request a certain number of acknowledgments for a write operation for the MongoDB cluster.- These acknowledgments represent increasing durability guarantees for a given write operations.
- Write concern comes with a trade off of write speed.
- The higher guarantee you need that a right is durable, the more time the overall write operation requires to complete.
- Replica sets, and sharded clusters all support write concern.
A write concern of zero means that the application doesn’t wait for any acknowledgments. The write might succeed or fail. The application doesn’t really care. It only checks that it can connect to the node successfully.
The default write concern is one . That means the application waits for an acknowledgment from a single member of the replica set, specifically, the primary. This is a baseline guarantee of success.
Write concerns greater than one increase the number of acknowledgments to include one or more secondary members. Higher levels of write concern correspond to a stronger guarantee of write durability.
Majority is a keyword that translates to a majority of replica set members. Divide the number of members by two and round up. So this three-member replica set has a majority of two. A five-member replica set would have a majority of three-- so on and so forth. The nice thing with majority is that you don’t have to update your write concern if you increase the size of your replica set.
Hope this helps
Michael