On the bitcoin blockchain, blocks contain transactions, and transactions contain information about who is sending what to whom e.g Bob is sending Alice 10 BTC.
This transaction must be created and signed by Bob (to prove he has the associated private key to send the funds from the address to Alice’s address). It must then be broadcast to nodes in the network so it can be validated and included in a block. Only once it has been included in a block and there have been a number of other blocks built on top of it, is it seen as confirmed. In general, a transaction with 6 block confirmations is seen as ‘certain’ and a transaction with less than 3 block confirmations is seen as potentially risky. This is due to the risk of block re-orgs, orphaned blocks or network forks.
However, each block on the bitcoin blockchain can include only 1MB worth of transactions — this is c2,500 transactions per block, and therefore there are many transactions which are waiting to be included within a block. They wait in something called a ‘mempool’ — short for ‘memory pool’.
When a miner is looking to build her next block, she selects transactions from this mempool and puts them into her candidate block — the block she’s hoping will be added to the blockchain if she can solve the cryptographic hash puzzle first. If Bob has added a suitably attractive transaction fee to his transaction then it is more likely to be selected by the miner from the mempool, if not then it may sit in the mempool until the blockchain becomes less busy or the going fee decreases towards it. If the miner is successful in having her block added to the blockchain then she gets to keep the transaction fees associated with all transactions in her block, as well as the 6.25 newly mined bitcoins.
Once a node receives a new transaction, it validates it and stores it within its local mempool. It can then be selected to be included within a candidate block, left in the mempool, or removed from the mempool if it’s included in another node’s confirmed block. It is very rare that two nodes have the exact same mempool since they will be receiving transaction broadcasts only from the nodes they are connected with, however, many mempools are broadly similar.
It is also possible to query another node’s mempool using an inventory message (referred to as an inv message) and receive a list of all transaction in that nodes’ mempool (unless a bloom filter is loaded and then only transaction matching the filter are received). This is useful when starting a node since the mempool will be empty by default and therefore the inv message to another node helps build up a picture of unconfirmed transactions within the network.
To view some mempool statistics from the Blockchain.com nodes check here: https://www.blockchain.com/en/charts/mempool-size