Hi @SuredaKuara,
I would avoid using arbiters if possible. For more elaboration on the downsides, see Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie_X.
You need at least two healthy voting members to elect or maintain a primary if there are three configured voting members in your replica set. If any two members of your replica set are down, a healthy third member will be a readonly secondary.
This avoids data inconsistency scenarios where a network partition could otherwise result in more than one primary. For example: member1 is down, the connection to the remote network is down, but member2 and member3 are healthy. If member2 and member3 could both decide to be primaries and accept writes, the data in these replica set members would diverge. The strict majority requirement ensures that a primary will only be present in a partition with a majority of voting members.
Since your original description had all requests originating via a local web server with unreliable internet I assumed you would prefer local availability, but you can plan your deployment to suit your failover and fault tolerance requirements.
Regards,
Stennie