MongoDB is strongly consistent by default - if you do a write and then do a read, assuming the write 
was successful you will always be able to read the result of the write you just read. 
This is because MongoDB is a single-master system and all reads go to the primary by default. 

If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent 
where it's possible to read out-of-date results. (MWA, 2016)

MongoDB also gets high-availability through automatic failover in replica sets: 
http://www.mongodb.org/display/DOCS/Replica+Sets

cfg = rs.conf()
cfg.settings = {}
cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
rs.reconfig(cfg)

// Requests acknowledgment that write operations have propagated to the majority of voting nodes, 
including the primary, and have been written to the on-disk journal for these nodes.

Availability in CAP is defined as “every request received by a non-failing [database] node in the 
system must result in a [non-error] response”. 
It’s not sufficient for some node to be able to handle the request: any non-failing node needs to 
be able to handle it. 

Many so-called “highly available” (i.e. low downtime) systems actually do not meet this definition 
of availability.

Cassandra provides consistency when RRC + WRC > N(RF) 
(read replica count + write replica count > replication factor).

Partition Tolerance (terribly mis-named) basically means that you’re communicating over an 
asynchronous network that may delay or drop messages. The internet and all our datacenters have this 
property, so you don’t really have any choice in this matter.