How did you handle the situation when accounts were distributed across different shards during transfers?

When accounts involved in transfers were located on different shards, there was a problem ensuring the atomicity and consistency of transactions. To address this situation, I used several approaches:

1. Two-Phase Commit — coordinating transactions across different shards to guarantee either complete execution or rollback.

2. Application-level orchestration — implementing transfer logic with state control and the ability to perform compensatory actions in case of errors.

3. Data re-sharding — changing the sharding scheme so that related accounts are on the same shard, if possible.

An example of simplified logic in Go with orchestration of transfers between shards:

func TransferFunds(fromShard, toShard Shard, fromAccount, toAccount string, amount float64) error {
    err := fromShard.Debit(fromAccount, amount)
    if err != nil {
        return err
    }
    err = toShard.Credit(toAccount, amount)
    if err != nil {
        // compensate the debit
        fromShard.Credit(fromAccount, amount)
        return err
    }
    return nil
}

This approach allows controlling the state and ensuring data integrity during cross-shard operations.