Zero-downtime resharding

A sharded transactional database has grown until one shard holds 40% of the data and is saturated; you must split it into smaller shards with zero downtime and no lost or duplicated writes, while the application keeps reading and writing it the whole time. Design the resharding process: how you copy the existing data to the new shards, how you keep them in sync with live writes during the (hours-long) copy, the cutover that switches traffic atomically, and how you make the whole thing safely abortable if something goes wrong midway.