Our understanding of CAP theorem has changed considerebly since its first appearance in 2000. There were a lot of confusion about the "chose-2-out-of-3" concept but Eric Brewer's article in 2012 nicely eliminated these confusions (I guess).

So, CAP theorem is not about being CA or AP or something else. It is simply this: Network partitions may happen all the time. It is unavoidable. And when a network partition happens, the architecture of a distributed database should allow its clients to tune consistency and availability as they wish.

What does this mean? Assume that you replicate a piece of data between 3 nodes (N1, N2, and N3 - so replication factor = 3) in a cluster. And let's say that a network partition happens which seperates N3 from N1 and N2:

So, all of the 3 nodes are operational, but the network between them is problematic right now. In this situation a client might make a read request or a write request to N1, N2 or N3. Based on the consistency choices of this client, the reaction of the cluster may differ:

• If the client makes a read request to N1, N1 can answer the query right away with its own data. Or N1 can forward the same query to N2 and compares its data with N2's data and returns the most up-to-date one. Here, the reaction of the cluster depends on the consistency choice of the client. Client tunes consistency according to its choices.
• Client can make a different choice too: It can force N1 to read data from all 3 nodes (i.e. read consistency of ALL in Cassandra terms). In this situation, cluster returns an error and we say that the cluster is not available accodring to the client's choice.
• Another possibility might be this one: Client might have asked the data to N3. In this situation, N3 only returns its data (read consistency = ONE) or the query fails (read consistency > 1).

I don't know about Mongo but this is how Cassandra works considering the CAP theorem.

C stands for eventual consistent. Correct ?

Consistency in the CAP theorem is referring to strong consistency where every read receives the most recent write or an error. By default MongoDB drivers direct all reads & writes to the primary of a replica set, which is strongly consistent.

The CAP theorem asserts that a distributed system must choose between consistency and availability in the event of a network partition. MongoDB's replica set approach uses a single primary for write consistency (CP), while Cassandra's replication strategy favours write availability (AP). Strong consistency is not possible with a network partition because there could be a conflict if both sides of the partition update the same data. To maintain write availability AP database systems need a solution for conflict resolution, which is a separate consideration from eventual consistency.

However, CAP is a simplification of real-world behaviour: MongoDB and Cassandra both have tunable levels of consistency for reads and writes. For example: MongoDB has write concerns to determine the level of acknowledgement required for write operations, read preferences for routing requests to members of a replica set, and read concerns to control the recency, consistency, and isolation properties of data read from replica set and sharded deployments.

Eric Brewer, author of the CAP Theorem, revisited this in 2012 with a more nuanced take: CAP Twelve Years Later: How the "Rules" Have Changed.

3. Till master is re-elected, write requests need to wait and system is not available

There are no writes without a primary, but replica sets still have read availability. MongoDB 3.6 added a Retryable Writes feature which helps applications better handle replica set elections and transient network errors.

4. Once the previous node(node crashed in step 2) comes back, writes pending from that node are written back to slaves.

If the primary in a MongoDB replica set becomes unavailable, the remaining members of the replica set will elect a new primary if there is an eligible secondary and a quorum of voting members. In your example, the voting majority would be 2/3 members of your replica set. Any writes accepted by a former primary that were not written to a majority of replica set members will be rolled back (saved to disk) so the former primary resumes syncing from a state consistent with the history of the current primary.