Transaction: Handle Proses Yang Mengharuskan Semua Query Harus Berhasil#

Dalam pembuatan sebuah service dalam pemrograman, terkadang ada beberapa proses database yang harus berhasil secara bersamaan.

Contohnya seperti transfer saldo, mengurangi stok barang, atau proses booking kursi. Jika salah satu proses gagal di tengah jalan, data bisa menjadi tidak sesuai, misalnya saldo berkurang tetapi tujuan tidak menerima uang, atau stok barang menjadi minus, dan itu akan membuat data menjadi inkonsisten dan berantakan,

Pada blog kali ini aku bakal bahas gimana caranya agar kesalahan tersebut tidak terulang lagi dan bisa di tanggulangi, langsung aja kita lanjut ke next section,

Yang pertama itu ada konsep ACID ( Atomicity, Consistency, Isolation, Durability )#

Konsep acid ini merupakan sekumpulan prinsip pada database transactions yang di gunakan untuk data agar tetap aman dan konsisten ketika sebuah proses logika dijalankan, sekarang kita coba lihat flow dibawah ini

di flow diatas kita sudah mendapatkan gimana gambaran flow dari acid itu sendiri di jalankan, jadi blog selesai, eits, belom dong

jadi gini dalam diagram diatas kita bisa lihat, kalo salah satu proses gagal, database dapat membatalkan seluruh perubahan agar data tetap aman dan tidak menjadi corrupt.

Lalu sebenarnya bagaimana cara kerja masing-masing konsep ACID tersebut? Mari kita bahas satu per satu.

1. Atomicity#

Atomicity itu bisa kita artikan sebagai satu kesatuan sebuah proses,

Artinya, jika ada beberapa query yang dijalankan dalam satu flow, maka semua query tersebut harus berhasil sampai akhir, dan jika salah satu query gagal, maka semua query yang sudah terjadi sebelumnya akan di kembalikan ke value sebelumnya.

Woiya bisa dong, di beberapa database seperti PostgreSQL, itu sangat memungkikan untuk melakukan proses ini, biasanya kita menggunakan bahasa sql prosedural,

Misalnya kita punya tabel wallets:

1
CREATE TABLE wallets (
2
  id SERIAL PRIMARY KEY,
3
  user_id INT NOT NULL,
4
  balance NUMERIC NOT NULL DEFAULT 0
5
);

Contoh datanya:

1
INSERT INTO wallets (user_id, balance)
2
VALUES
3
  (1, 100000),
4
  (2, 50000);

Lalu kita buat function untuk transfer saldo:

1
CREATE OR REPLACE FUNCTION transfer_balance(
2
  sender_id INT,
3
  receiver_id INT,
4
  amount NUMERIC
5
)
6
RETURNS VOID AS $$
7
BEGIN
8
  UPDATE wallets
9
  SET balance = balance - amount
10
  WHERE user_id = sender_id;
11

12
  UPDATE wallets
13
  SET balance = balance + amount
14
  WHERE user_id = receiver_id;
15
END;
16
$$ LANGUAGE plpgsql;

Function tersebut bisa dijalankan seperti ini:

1
SELECT transfer_balance(1, 2, 25000);

Di PostgreSQL, function PL/pgSQL berjalan di dalam transaction. Jadi jika salah satu query di dalam function gagal, seluruh proses akan dibatalkan.

Namun, function di atas masih punya masalah. Kita belum memastikan saldo pengirim cukup.

Versi yang lebih aman bisa seperti ini:

1
CREATE OR REPLACE FUNCTION transfer_balance(
2
  sender_id INT,
3
  receiver_id INT,
4
  amount NUMERIC
5
)
6
RETURNS VOID AS $$
7
DECLARE
8
  sender_balance NUMERIC;
9
BEGIN
10
  SELECT balance
11
  INTO sender_balance
12
  FROM wallets
13
  WHERE user_id = sender_id;
14

15
  IF sender_balance < amount THEN
16
    RAISE EXCEPTION 'Saldo tidak cukup';
17
  END IF;
18

19
  UPDATE wallets
20
  SET balance = balance - amount
21
  WHERE user_id = sender_id;
22

23
  UPDATE wallets
24
  SET balance = balance + amount
25
  WHERE user_id = receiver_id;
26
END;
27
$$ LANGUAGE plpgsql;

Dengan function ini, proses transfer hanya akan dilanjutkan jika saldo pengirim mencukupi.

Jika saldo tidak cukup, PostgreSQL akan menjalankan RAISE EXCEPTION, lalu seluruh proses dalam transaction akan gagal dan perubahan tidak akan disimpan.

Inilah contoh penerapan Atomicity:

Semua proses transfer berhasil, atau tidak ada perubahan sama sekali.

2. Consistency#

Setelah sebelumnya kita membahas tentang Atomicity, sekarang kita lanjut ke konsep berikutnya yaitu Consistency.

Consistency berarti data harus tetap valid sebelum dan sesudah transaction dijalankan.

Misalnya:

• Saldo nya gakboleh jadi minus.
• Stock ga boleh jadi minus.
• User Gaboleh duplikat,
• Segala sesuatu tindakan yang mengubah value data menjadi anomali seperti sosok monyet ijo banyumas

Nah simple nya gini deh kita coba lanjut ke kasus permasalahanya

Bayangkan kita punya tabel products seperti ini:

1
CREATE TABLE products (
2
  id SERIAL PRIMARY KEY,
3
  product_name TEXT NOT NULL,
4
  stock INT NOT NULL
5
);

Contoh datanya:

1
INSERT INTO products (product_name, stock)
2
VALUES
3
  ('Keyboard Mechanical', 5);

Sekarang kita coba membuat function untuk mengurangi stok barang ketika user checkout.

1
CREATE OR REPLACE FUNCTION reduce_stock(
2
  product_id INT,
3
  total INT
4
)
5
RETURNS VOID AS $$
6
BEGIN
7
  UPDATE products
8
  SET stock = stock - total
9
  WHERE id = product_id;
10
END;
11
$$ LANGUAGE plpgsql;

Kelihatannya aman…

Tapi coba bayangkan jika ada request seperti ini:

1
SELECT reduce_stock(1, 10);

Padahal stok awal cuma 5.

Akibatnya?

stock = -5

Nah, data seperti ini sudah tidak nguwawor rek ini udah ngelanggar konsep flow bisnis dan bisa di parani user nanti wkwkwkwkwk

1
CREATE OR REPLACE FUNCTION reduce_stock(
2
  product_id INT,
3
  total INT
4
)
5
RETURNS VOID AS $$
6
DECLARE
7
  current_stock INT;
8
BEGIN
9
  SELECT stock
10
  INTO current_stock
11
  FROM products
12
  WHERE id = product_id;
13

14
  IF current_stock < total THEN
15
    RAISE EXCEPTION 'Stock tidak mencukupi';
16
  END IF;
17

18
  UPDATE products
19
  SET stock = stock - total
20
  WHERE id = product_id;
21
END;
22
$$ LANGUAGE plpgsql;

3. Isolation#

Isolation ini berarti beberapa transaction yang berjalan secara bersamaan tidak boleh saling mengganggu yang lain.

Hal ini penting karena dalam aplikasi nyata, sering kali ada banyak user yang mengakses data yang sama di waktu bersamaan dan bisa menyebabkan yang namanya Race Condition.

Contoh Kasus#

Bayangkan ada 2 user kita sebut aja mas amba dan mas rusdi yang ingin booking kursi yang sama secara bersamaan.

Misalnya kita punya tabel:

1
CREATE TABLE seats (
2
  id SERIAL PRIMARY KEY,
3
  seat_number TEXT,
4
  is_booked BOOLEAN DEFAULT FALSE
5
);

Lalu mas amba dan mas rusdi menjalankan proses booking hampir di waktu yang sama.

Tanpa Isolation yang baik, keduanya bisa saja membaca data:

1
is_booked = false

Akibatnya:

• Mas Amba berhasil booking
• Mas Rusdi juga berhasil booking

Padahal kursinya cuma satu ( Ngawur cik kalo 1 kursi mau di pangku" an apa gimana )

1
CREATE OR REPLACE FUNCTION book_seat(
2
  seat_id INT
3
)
4
RETURNS VOID AS $$
5
DECLARE
6
  seat_status BOOLEAN;
7
BEGIN
8
  SELECT is_booked
9
  INTO seat_status
10
  FROM seats
11
  WHERE id = seat_id
12
  FOR UPDATE;
13

14
  IF seat_status THEN
15
    RAISE EXCEPTION 'Kursi sudah dibooking';
16
  END IF;
17

18
  UPDATE seats
19
  SET is_booked = TRUE
20
  WHERE id = seat_id;
21
END;
22
$$ LANGUAGE plpgsql;

4. Durability#

Konsep terakhir adalah Durability.

Durability bisa kita artikan kalo data yang sudah berhasil di-commit atau di proses oleh sistem, maka tidak boleh hilang, bahkan jika terjadi crash, listrik mati, atau server restart.

Simpelnya gini kalo transaction sudah dianggap berhasil, maka data harus tetap tersimpan.

1
SELECT transfer_balance(1, 2, 25000);

1
COMMIT;