Sharding aims to solve the scalability trilemma (Scalability, Decentralization, Security). It works by splitting up the verification job amongst randomly selected validators that form their own committee. A validator publishes a signature attesting that they did their job, and the other validators verify this signature (e.g. via BLS signature aggregation). This way instead of 10k validators each verifying 100 blocks, they're mining a few blocks in each committee and verifying the signatures of the 10k validators.
Blocks are broadcast on subnets instead of p2p to all validators. In Big O Notation, the sharded chain's capacity is O(C^2), growing quadratically (aka quadratic sharding).
We want to have a sharding solution that avoids 51% trust assumptions for validation. Validation problem is two parts: validating computation, and validating data availability. The former relies on either [fraud-proofs] or [zk-snarks]. The data availability problem (i.e. "how do you check that 1 MB of data is available without actually trying to download it?") can be solved via [data-availability-sampling] which makes it feasible to run data availability checking on every block.
In the case of Ethereum sharding, the near-term plan is to make sharded blocks data-only; that is, the shards are purely a "data availability engine", and it's the job of layer-2 rollups to use that secure data space, plus either fraud proofs or ZK-SNARKs, to implement high-throughput secure transaction processing capabilities. However, it's completely possible to create such a built-in system to add "native" high-throughput execution.
Transactions between shards are asynchronous (not atomic), however many transactions could work under this model.
Cross-shard communication could be achieved using a receipt proof concept,
Further types of cross-shard communication challenges: What is the train-and-hotel problem?.