SQL Server Error 1205

A deadlock victim can almost always succeed on a second attempt because the other transaction has finished. Catch error 1205 in a TRY/CATCH block (or in the client) and rerun the whole transaction a few times with a short backoff.

DECLARE @attempt INT = 0;
WHILE @attempt < 3
BEGIN
    BEGIN TRY
        BEGIN TRAN;
        UPDATE dbo.Accounts SET balance = balance - 100 WHERE id = 1;
        UPDATE dbo.Accounts SET balance = balance + 100 WHERE id = 2;
        COMMIT;
        BREAK;  -- success, leave the loop
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0 ROLLBACK;
        IF ERROR_NUMBER() = 1205 AND @attempt < 2
        BEGIN
            SET @attempt = @attempt + 1;
            WAITFOR DELAY '00:00:00.100';  -- brief backoff, then retry
        END
        ELSE
            THROW;  -- not a deadlock, or out of retries
    END CATCH
END

Most deadlocks come from two transactions touching the same objects in the opposite order. If every transaction always updates row id = 1 before row id = 2 (and table A before table B), no cycle can form. Pick one canonical order and use it everywhere.

-- Both sessions update the lower id first, then the higher id.
BEGIN TRAN;
UPDATE dbo.Accounts SET balance = balance - 100 WHERE id = 1;
UPDATE dbo.Accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

The longer a transaction holds locks, the more likely another session collides with it. Do validation and lookups before you open the transaction, keep only the writes inside it, and commit as soon as the work is done. Never wait for user input while a transaction is open.

-- Prepare values first, outside the transaction.
DECLARE @amount MONEY = 100;

-- Open the transaction only for the writes, then commit at once.
BEGIN TRAN;
UPDATE dbo.Accounts SET balance = balance - @amount WHERE id = 1;
UPDATE dbo.Accounts SET balance = balance + @amount WHERE id = 2;
COMMIT;

Without a useful index, an UPDATE or DELETE scans and locks far more rows than it changes, which widens the window for a deadlock. Index the columns in your WHERE clause so the engine seeks straight to the rows it needs and locks only those.

-- A seek on this index locks just the matching rows,
-- instead of a scan that locks the whole table.
CREATE INDEX IX_Accounts_CustomerId
    ON dbo.Accounts (customer_id);

Many deadlocks involve a reader and a writer blocking each other. Turning on Read Committed Snapshot Isolation (RCSI) makes readers use row versions instead of shared locks, so a SELECT no longer waits on a writer. This removes a large class of deadlocks with no code change.

ALTER DATABASE CURRENT SET READ_COMMITTED_SNAPSHOT ON
    WITH ROLLBACK IMMEDIATE;

To fix a deadlock you first need to see which statements and resources form the cycle. Turn on trace flag 1222 to write the deadlock graph to the error log, or capture the xml_deadlock_report event with Extended Events, then read the graph to see exactly which two statements collided. See error 1222 for reading the graph output.

-- Write full deadlock details to the SQL Server error log.
DBCC TRACEON (1222, -1);

-- Or capture the deadlock graph with Extended Events.
CREATE EVENT SESSION deadlocks ON SERVER
    ADD EVENT sqlserver.xml_deadlock_report
    ADD TARGET package0.ring_buffer;
ALTER EVENT SESSION deadlocks ON SERVER STATE = START;