Your application's ability to write depends on the Write Concern used. With default w:1, writes may continue in both data centers but risk data loss and rollbacks. With w: 'majority', writes stop completely if DC-A loses connection to DC-B.
When the network link between your two data centers fails, the replica set experiences a network partition, splitting into two sides: the side with two nodes (DC-A) and the isolated side with one node (DC-B). The behavior of your application's writes depends critically on your configured write concern and which nodes can participate in an election.
In a 3-node replica set, a majority is 2 nodes . The side with two nodes (DC-A) has a majority and can therefore hold an election and elect a new primary from among its members . The isolated node in DC-B cannot form a majority on its own and will step down if it was the primary, or remain a secondary if it wasn't. Writes can only be performed on a primary node .
If your application uses w: 'majority' (the default in MongoDB 5.0+ drivers ), a write must be acknowledged by a majority of the replica set's voting members .
With w: 1, a write is acknowledged as soon as the primary applies it to its in-memory data set.
The MongoDB documentation explicitly warns about this situation: two nodes may transiently believe they are primary, but only one can complete w: 'majority' writes . The other node, typically due to a network partition, will have its writes rolled back.