Fundamental Basis Data Relasional
untuk Backend Skincare

Sebelum query, pahami dulu bentuk dan aturan datanya

Backend e-commerce tidak hanya menyimpan JSON. Ia menjaga agar stok, order, pembayaran, dan user tetap konsisten walau ribuan request masuk bersamaan. Itu pekerjaan basis data, bukan handler.

Roadmap 2 berhenti tepat di titik menarik: kita sudah punya permukaan REST API utuh (katalog, cart, checkout, order, payment webhook), tetapi semua service-nya masih in-memory. Sekarang data itu butuh rumah permanen. Pertanyaannya bukan sekadar “database mana”, melainkan “bentuk data seperti apa yang membuat API tadi tetap benar saat dipakai sungguhan”.

Kalau kamu datang dari React, data sering terlihat sebagai array of object di state, lalu dikirim sebagai JSON ke API. Kalau datang dari Laravel, kamu mungkin terbiasa dengan model Eloquent dan migration. Di balik keduanya, basis data relasional bekerja dengan kontrak yang jauh lebih ketat: data ditempatkan dalam tabel, dihubungkan dengan key, dan dijaga oleh constraint yang aktif bahkan saat kode aplikasimu salah.

Di proyek online shop skincare, kita akan menyimpan user, brand, produk beserta varian, kategori, inventory, cart, order, item order, payment, shipment, review, dan promosi. Kalau relasi dasarnya salah, kode Go yang rapi tetap akan menderita, karena bug berpindah ke layer service, handler, dan worker. Modul ini menanam fondasi itu, hampir tanpa kode Go, supaya tiga modul berikutnya (SQL dasar, pgxpool, transaksi) berdiri di atas tanah yang stabil.

Rujukan resmi yang relevan untuk modul ini adalah dokumentasi PostgreSQL tentang constraints, index, transaction, isolasi transaksi, tipe JSON, dan full-text search. Kita tidak menyalin dokumentasi itu, melainkan memakai konsepnya untuk mendesain backend skincare yang benar sejak awal.

Bayangkan spreadsheet, tetapi dengan aturan yang ditegakkan mesin

Tabel adalah tempat data sejenis dikumpulkan, baris adalah satu record, kolom adalah atribut yang punya nama, tipe, dan makna yang dijaga database.

Spreadsheet bagus untuk membayangkan bentuk data. Ada header kolom, ada baris, ada nilai di tiap sel. Bedanya, PostgreSQL tidak menerima data sembarang setelah kamu mendefinisikan kolom dan constraint. Kolom price_rupiah bisa dibuat bigint, slug bisa dibuat unik, created_at bisa dibuat wajib ada dengan default now(). Aturan itu hidup di skema, bukan di kepala developer.

Kita pakai tabel product_variants sebagai contoh utama sepanjang modul, karena di toko skincare varian (SKU) adalah unit yang benar-benar dijual dan menyimpan harga. Satu produk “Hyaluronic Acid Serum” bisa punya beberapa varian ukuran (30ml, 50ml), dan tiap varian punya price_rupiah sendiri.

Contoh isi tabel product_variantsSalin
id | product_id | sku        | variant_name | price_rupiah | is_active
1  | 7          | SRM-HA-30  | 30 ml        | 139000       | true
2  | 7          | SRM-HA-50  | 50 ml        | 199000       | true
3  | 12         | SPF-50-PA  | 50 ml        | 119000       | false

Di SQL, bentuk data ini diterjemahkan menjadi CREATE TABLE. Untuk modul ini fokusnya bukan menghafal sintaks, tetapi membaca maksud desainnya. Perhatikan tiga hal: identitas (id), referensi ke produk induk (product_id), dan uang sebagai integer rupiah (price_rupiah bigint), bukan pecahan.

migrations/000002_create_catalog.up.sql (potongan product_variants)Salin
CREATE TABLE product_variants (
  id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  product_id   bigint NOT NULL REFERENCES products (id) ON DELETE CASCADE,
  sku          text   NOT NULL UNIQUE,
  variant_name text   NOT NULL,
  size_label   text,
  price_rupiah bigint NOT NULL CHECK (price_rupiah >= 0),
  is_active    boolean NOT NULL DEFAULT true,
  created_at   timestamptz NOT NULL DEFAULT now(),
  updated_at   timestamptz NOT NULL DEFAULT now()
);

Satu detail penting yang sudah kita putuskan untuk seluruh proyek: uang selalu bigint dalam satuan rupiah utuh. Tidak ada numeric, tidak ada float, tidak ada _cents. Alasannya dibahas tuntas di bagian ACID, tetapi pegang dulu konvensinya sejak baris pertama kamu membaca skema.

Satu order, dua filosofi penyimpanan yang sangat berbeda

Cara tercepat memahami “kenapa relasional” adalah membandingkan bagaimana satu order disimpan sebagai dokumen tunggal di MongoDB/Firestore versus sebagai beberapa baris terhubung di PostgreSQL.

Di dunia dokumen (MongoDB, Firestore), godaan alaminya adalah menyimpan seluruh order sebagai satu blob JSON: data user di-embed, daftar item di-embed sebagai array, snapshot produk ikut menempel. Terasa nyaman karena satu kali baca langsung dapat semuanya. Tetapi konsistensi, integritas, dan query lintas-entitas menjadi tanggung jawab aplikasi sepenuhnya.

order sebagai satu dokumen (gaya MongoDB / Firestore)Salin
{
  "id": "ord_8f3",
  "user": { "id": "u_12", "email": "tata@mail.com", "name": "Tata" },
  "items": [
    { "variant_id": "v_7", "name": "Serum HA 30ml", "price": 139000, "qty": 2 },
    { "variant_id": "v_9", "name": "Sunscreen SPF50", "price": 119000, "qty": 1 }
  ],
  "total": 397000,
  "status": "pending"
}

Di dunia relasional, order yang sama dipecah menjadi baris di beberapa tabel yang saling menunjuk lewat foreign key. orders memegang fakta tingkat order (total, status, user), sedangkan order_items memegang tiap baris item dan menunjuk balik ke orders.id. Data user tidak di-embed, cukup direferensikan lewat user_id.

order yang sama, terpecah relasionalSalin
orders
  id | user_id | order_number | status  | subtotal_rupiah | total_rupiah
  1  | 12      | INV-2026-001 | pending | 397000          | 397000

order_items
  id | order_id | variant_id | product_name      | unit_price_rupiah | quantity
  1  | 1        | 7          | Serum HA 30ml     | 139000            | 2
  2  | 1        | 9          | Sunscreen SPF50   | 119000            | 1

flowchart LR
  subgraph DOC["Dokumen blob (1 JSON)"]
    D["order { user, items[], total, status }"]
  end
  subgraph REL["Relasional (baris terhubung)"]
    U["users"] -->|user_id| O["orders"]
    O -->|order_id| OI["order_items"]
    OI -->|variant_id| V["product_variants"]
  end
  DOC -.->|"di-normalisasi jadi"| REL

Gambar 1. Satu order sebagai dokumen tunggal versus sebagai baris-baris yang terhubung lewat foreign key. Yang kiri cepat dibaca utuh, yang kanan aman dipakai lintas laporan, refund, dan rekonsiliasi.

Setiap baris penting harus bisa ditunjuk secara unik dan stabil

Primary key adalah identitas unik untuk satu baris, mirip id stabil yang kamu pakai saat render list React, tetapi jauh lebih formal dan ditegakkan database.

Di React kamu memberi key={variant.id} agar reconciler tahu item mana yang berubah. Di database, primary key punya peran lebih besar: ia adalah cara aman mengidentifikasi satu baris, target yang ditunjuk foreign key dari tabel lain, dan jangkar untuk update, delete, dan audit. Kalau identitasnya goyah, seluruh relasi ikut goyah.

Konvensi proyek kita: setiap tabel inti memakai id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY. Ini pengganti modern untuk serial, dan GENERATED ALWAYS mencegah aplikasi keliru menyetel id secara manual. Angka bigint memberi ruang jauh lebih besar daripada integer biasa, penting untuk tabel yang tumbuh seperti order_items dan payments.

migrations/000001_create_users.up.sql (potongan)Salin
CREATE TABLE users (
  id            bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name          text NOT NULL,
  email         text NOT NULL UNIQUE,
  password_hash text NOT NULL,
  role          text NOT NULL DEFAULT 'customer'
                  CHECK (role IN ('customer', 'admin')),
  created_at    timestamptz NOT NULL DEFAULT now(),
  updated_at    timestamptz NOT NULL DEFAULT now(),
  deleted_at    timestamptz
);

Kenapa jangan memakai email sebagai primary key user? Karena email adalah atribut bisnis yang bisa berubah. Customer mengganti email, admin memperbaiki typo, login bisa berpindah provider. Primary key sebaiknya stabil, tanpa makna bisnis yang gampang berubah, dan aman menjadi referensi dari orders, addresses, reviews, dan tabel lain. email tetap penting, jadi kita jaga keunikannya lewat UNIQUE, bukan menjadikannya identitas.

Ada kalanya primary key bukan satu kolom, melainkan gabungan beberapa kolom. Tabel penghubung product_categories memetakan produk ke kategori secara many-to-many, dan identitas barisnya adalah pasangan (product_id, category_id). Ini disebut composite primary key, dan ia sekaligus mencegah satu produk dipasangkan ke kategori yang sama dua kali.

migrations/000002_create_catalog.up.sql (potongan product_categories)Salin
CREATE TABLE product_categories (
  product_id  bigint NOT NULL REFERENCES products (id) ON DELETE CASCADE,
  category_id bigint NOT NULL REFERENCES categories (id) ON DELETE RESTRICT,
  PRIMARY KEY (product_id, category_id)
);

Relasi bukan komentar di kode, relasi harus ditegakkan database

Foreign key memastikan nilai di satu tabel benar-benar menunjuk baris yang ada di tabel lain. Inilah penjaga yang membuat data yatim mustahil tersimpan.

Kalau orders punya user_id, kita tidak mau ada order dengan user_id yang tidak pernah ada di users. Di layer Go kamu bisa mengecek user dulu sebelum membuat order. Tetapi pengecekan aplikasi saja tidak cukup, karena ada race condition, worker latar, script admin, migration, dan proses lain yang juga menulis ke database. Foreign key membuat aturan itu berlaku untuk semua jalur penulisan, bukan hanya jalur yang kamu ingat.

migrations/000005_create_orders.up.sql (potongan orders)Salin
CREATE TABLE orders (
  id              bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id         bigint NOT NULL REFERENCES users (id) ON DELETE RESTRICT,
  order_number    text   NOT NULL UNIQUE,
  idempotency_key text   NOT NULL UNIQUE,
  status          text   NOT NULL DEFAULT 'pending',
  subtotal_rupiah bigint NOT NULL CHECK (subtotal_rupiah >= 0),
  total_rupiah    bigint NOT NULL CHECK (total_rupiah >= 0),
  created_at      timestamptz NOT NULL DEFAULT now()
);

Di contoh ini, orders.user_id tidak boleh menunjuk user fiktif. Kalau baris user tidak ada, PostgreSQL menolak insert order dengan error. Inilah beda desain data yang “berharap kode selalu benar” dengan desain data yang punya pagar bawaan.

Bagian yang sering terlewat adalah perilaku saat penghapusan. Klausa ON DELETE menentukan nasib baris anak ketika induknya dihapus, dan pilihannya adalah keputusan bisnis, bukan teknis semata.

Untuk online shop, relasi order dan varian produk tidak ditulis sebagai orders.variant_id, karena satu order berisi banyak varian. Kita butuh tabel anak order_items, dan tiap baris menunjuk dua induk sekaligus: order tempatnya bernaung, dan varian yang dibeli.

migrations/000005_create_orders.up.sql (potongan order_items)Salin
CREATE TABLE order_items (
  id                bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id          bigint NOT NULL REFERENCES orders (id) ON DELETE CASCADE,
  variant_id        bigint NOT NULL REFERENCES product_variants (id) ON DELETE RESTRICT,
  product_name      text   NOT NULL,
  sku               text   NOT NULL,
  unit_price_rupiah bigint NOT NULL CHECK (unit_price_rupiah >= 0),
  quantity          integer NOT NULL CHECK (quantity > 0),
  created_at        timestamptz NOT NULL DEFAULT now()
);

Perhatikan unit_price_rupiah, product_name, dan sku. Kita menyimpan harga dan nama saat checkout, bukan hanya membaca data terbaru dari product_variants. Kalau harga serum berubah besok, total order kemarin tidak boleh ikut berubah. Inilah snapshot, dan kita bahas alasannya lebih dalam di bagian normalisasi.

Validasi bukan hanya tugas handler dan service

Constraint adalah aturan database yang menolak data tidak valid, bahkan ketika bug di aplikasi mencoba menyimpannya. Ia adalah pagar terakhir, bukan pagar pertama.

Di Roadmap 2 kita memvalidasi request di handler dengan []httpx.FieldError. Di Roadmap 4 service layer akan memvalidasi aturan bisnis. Tetapi constraint tetap diperlukan karena database adalah sumber kebenaran terakhir untuk integritas data. Tiga lapis validasi ini saling melengkapi, bukan saling menggantikan.

Tabel constraint berikut merangkum jenis utama beserta contoh konkret dari skema skincare, supaya kamu bisa membaca skema apa pun lebih cepat.

Tabel 1. Jenis constraint utama PostgreSQL dan perannya di skema online shop skincare.

migrations/000002_create_catalog.up.sql (constraint pada product_variants)Salin
CREATE TABLE product_variants (
  id                      bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  product_id              bigint  NOT NULL REFERENCES products (id) ON DELETE CASCADE,
  sku                     text    NOT NULL UNIQUE,
  variant_name            text    NOT NULL,
  price_rupiah            bigint  NOT NULL CHECK (price_rupiah >= 0),
  compare_at_price_rupiah bigint  CHECK (
                            compare_at_price_rupiah IS NULL
                            OR compare_at_price_rupiah >= price_rupiah),
  is_active               boolean NOT NULL DEFAULT true
);

CHECK tidak harus hanya melihat satu kolom. compare_at_price_rupiah >= price_rupiah adalah CHECK lintas kolom yang menjamin “harga coret” tidak pernah lebih kecil dari harga jual. Aturan bisnis seperti ini lebih aman dipasang di database daripada hanya diingat di service.

Pilih bentuk relasi dari aturan bisnis, bukan dari kenyamanan query pertama

Relasi adalah cara menyatakan hubungan antar konsep bisnis, seperti user memiliki banyak order, satu varian punya satu baris inventory, dan satu produk masuk banyak kategori.

Tiga bentuk relasi ini menutup hampir semua kebutuhan e-commerce. Yang membedakan bukan teknis, melainkan pertanyaan bisnis: berapa banyak sisi A boleh dipasangkan ke berapa banyak sisi B.

One-to-one: varian dan inventory

One-to-one berarti satu baris di tabel A terkait maksimal dengan satu baris di tabel B. Di proyek skincare, satu varian punya tepat satu baris stok. Kita memisahkan inventories dari product_variants karena stok berubah jauh lebih sering daripada data varian, dan memisahkannya mempermudah penguncian baris saat checkout. Kunci one-to-one adalah UNIQUE pada kolom foreign key sisi anak.

migrations/000003_create_inventory.up.sql (potongan inventories)Salin
CREATE TABLE inventories (
  id                 bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  variant_id         bigint NOT NULL UNIQUE
                       REFERENCES product_variants (id) ON DELETE CASCADE,
  quantity_available integer NOT NULL DEFAULT 0 CHECK (quantity_available >= 0),
  quantity_reserved  integer NOT NULL DEFAULT 0 CHECK (quantity_reserved >= 0),
  updated_at         timestamptz NOT NULL DEFAULT now(),
  CHECK (quantity_available >= quantity_reserved)
);

One-to-many: user dan order

One-to-many berarti satu baris induk punya banyak baris anak. Satu user punya banyak order, tetapi satu order hanya milik satu user. Foreign key selalu ditaruh di sisi “many”, yaitu orders.user_id. Inilah relasi paling umum di basis data relasional, dan hampir setiap tabel anak di skema kita mengikuti pola ini.

contoh konsep one-to-manySalin
-- users (1) ---> (banyak) orders
-- orders.user_id menunjuk users.id
-- carts (1) ---> (banyak) cart_items
-- cart_items.cart_id menunjuk carts.id

Many-to-many: produk dan kategori

Many-to-many berarti satu produk bisa masuk banyak kategori, dan satu kategori berisi banyak produk. Relasi ini tidak bisa diwakili satu foreign key di salah satu sisi. Solusinya adalah tabel penghubung (join table) product_categories yang berisi sepasang foreign key dan menjadikannya composite primary key. Pola yang sama dipakai promotion_products untuk memetakan promo ke produk tertentu.

erDiagram
  USERS ||--o{ ORDERS : places
  ORDERS ||--o{ ORDER_ITEMS : contains
  PRODUCT_VARIANTS ||--o{ ORDER_ITEMS : snapshot_from
  PRODUCT_VARIANTS ||--|| INVENTORIES : stocked_as
  PRODUCTS ||--o{ PRODUCT_VARIANTS : has
  PRODUCTS ||--o{ PRODUCT_CATEGORIES : tagged_as
  CATEGORIES ||--o{ PRODUCT_CATEGORIES : groups
  ORDERS ||--o{ PAYMENTS : paid_by

  USERS {
    bigint id PK
    text email UK
    text role
  }
  ORDERS {
    bigint id PK
    bigint user_id FK
    text order_number UK
    bigint total_rupiah
  }
  ORDER_ITEMS {
    bigint id PK
    bigint order_id FK
    bigint variant_id FK
    bigint unit_price_rupiah
    integer quantity
  }
  PRODUCTS {
    bigint id PK
    text slug UK
    text status
  }
  PRODUCT_VARIANTS {
    bigint id PK
    bigint product_id FK
    text sku UK
    bigint price_rupiah
  }
  INVENTORIES {
    bigint id PK
    bigint variant_id FK
    integer quantity_available
  }
  PRODUCT_CATEGORIES {
    bigint product_id FK
    bigint category_id FK
  }
  CATEGORIES {
    bigint id PK
    text slug UK
  }
  PAYMENTS {
    bigint id PK
    bigint order_id FK
    bigint amount_rupiah
  }

Gambar 2. Inti relasi skincare: user membuat order (one-to-many), order memuat item snapshot dari varian, varian punya satu inventory (one-to-one), dan produk masuk banyak kategori lewat join table (many-to-many).

Kapan memecah data, kapan sengaja menduplikasinya

Normalisasi adalah disiplin menata kolom agar tiap fakta disimpan satu kali di tempat yang tepat. Denormalisasi dan snapshot adalah pengecualian yang disengaja, dengan alasan yang jelas.

Kamu tidak perlu menghafal teori normalisasi formal. Tiga tingkat pertama (1NF sampai 3NF) bisa diringkas jadi aturan praktis yang langsung berguna saat membaca skema skincare.

flowchart LR
  RAW["1 tabel gemuk:<br/>order + user + brand + harga hidup"]
  RAW -->|1NF: pisah daftar| A["join table untuk kategori"]
  RAW -->|2NF/3NF: pisah entitas| B["users, brands, products terpisah"]
  B -->|referensi by id| C["orders cukup simpan user_id"]
  C -->|kecuali harga| D["order_items snapshot harga (sengaja)"]

Gambar 3. Dari satu tabel gemuk menuju skema ternormalisasi, dengan satu pengecualian yang disengaja: harga di order dibekukan sebagai snapshot.

Normalisasi punya batas. Kadang join terus-menerus mahal, atau sebuah fakta memang harus dibekukan pada momen tertentu. Di situ kita memilih denormalisasi atau snapshot secara sadar, bukan karena malas.

Inilah kenapa order_items menyimpan product_name, sku, dan unit_price_rupiah sendiri, padahal semuanya juga ada di product_variants. Ini bukan pelanggaran normalisasi yang ceroboh, melainkan keputusan bisnis: invoice adalah dokumen historis. Order yang sudah jadi harus tetap menampilkan harga dan nama saat pembelian, walau katalog berubah, varian dinonaktifkan, atau brand berganti nama.

Index mempercepat baca, tetapi tidak gratis

Index adalah struktur data tambahan yang membantu PostgreSQL menemukan baris jauh lebih cepat tanpa membaca seluruh tabel.

Bayangkan mencari varian dengan SKU SRM-HA-30. Tanpa index, database mungkin perlu memeriksa banyak baris satu per satu (sequential scan). Dengan index pada sku, database punya jalur pencarian yang jauh lebih efisien (index scan). Dokumentasi PostgreSQL menegaskan index mempercepat pencarian baris, tetapi juga menambah overhead, jadi harus dipakai dengan sadar.

Beberapa index sebenarnya lahir otomatis dari constraint. PRIMARY KEY dan UNIQUE membuat unique index di belakang layar, jadi users.email dan product_variants.sku sudah ter-index tanpa kamu menulis apa-apa. Sisanya kamu buat mengikuti pola query nyata.

migrations/000005_create_orders.up.sql (index yang dibuat mengikuti query)Salin
-- Riwayat order per user, terbaru dulu: GET /v1/orders
CREATE INDEX orders_user_id_created_at_idx
  ON orders (user_id, created_at DESC);

-- Item milik satu order: detail order dan invoice
CREATE INDEX order_items_order_id_idx
  ON order_items (order_id);

-- Filter status untuk dashboard admin
CREATE INDEX orders_status_idx ON orders (status);

Index orders (user_id, created_at DESC) adalah composite index. Ia berguna untuk WHERE user_id = $1 ORDER BY created_at DESC, persis pola endpoint riwayat order. Aturan leftmost-prefix berlaku: index ini juga membantu WHERE user_id = $1 saja, tetapi tidak membantu WHERE created_at > $1 tanpa menyebut user_id. Urutan kolom di index adalah keputusan desain, bukan kebetulan.

Kita akan mendalami EXPLAIN (ANALYZE), index parsial, dan GIN untuk full-text search di modul indexing lanjutan. Untuk sekarang cukup pegang prinsipnya: kolom yang sering dipakai untuk filter, join, sort, dan keunikan adalah kandidat index utama.

Checkout adalah momen paling rawan di seluruh backend

ACID adalah jaminan yang membuat checkout aman: serangkaian perubahan berhasil semua atau dibatalkan semua, tanpa pernah meninggalkan order setengah jadi atau stok yang salah hitung.

Checkout bukan satu insert. Ia menyentuh banyak baris: mengurangi quantity_available di inventories, membuat baris orders, membuat beberapa baris order_items dengan harga snapshot, lalu mungkin membuat baris payments. Kalau salah satu langkah gagal di tengah (misalnya stok ternyata habis), semua langkah sebelumnya harus dibatalkan. Tanpa atomicity, kamu bisa berakhir dengan stok berkurang tetapi order tidak pernah tercatat, alias uang dan barang menguap.

konsep checkout dalam satu transaksiSalin
BEGIN;

-- Kurangi stok hanya jika cukup; baris dikunci selama transaksi
UPDATE inventories
SET quantity_available = quantity_available - 2
WHERE variant_id = 7 AND quantity_available >= 2;

-- Buat order dan item dengan harga yang dibekukan
INSERT INTO orders (user_id, order_number, idempotency_key,
                    subtotal_rupiah, total_rupiah)
VALUES (12, 'INV-2026-001', 'chk-1f2e', 278000, 278000);

INSERT INTO order_items (order_id, variant_id, product_name, sku,
                         unit_price_rupiah, quantity)
VALUES (1, 7, 'Serum HA 30ml', 'SRM-HA-30', 139000, 2);

COMMIT;  -- gagal di tengah? ROLLBACK membatalkan semuanya

sequenceDiagram
  participant API as Go API (pgx)
  participant DB as PostgreSQL
  API->>DB: BEGIN
  API->>DB: UPDATE inventories (kurangi stok, kunci baris)
  alt stok cukup
    API->>DB: INSERT orders
    API->>DB: INSERT order_items (harga snapshot)
    API->>DB: COMMIT
    DB-->>API: order tercatat, stok benar
  else stok tidak cukup
    API->>DB: ROLLBACK
    DB-->>API: tidak ada perubahan sama sekali
  end

Gambar 4. Checkout dibungkus satu transaksi. Atomicity menjamin tidak ada keadaan setengah jadi: stok berkurang dan order tercatat bersama, atau tidak terjadi apa-apa.

Isolation menjaga dua checkout bersamaan atas varian terakhir tidak sama-sama lolos. PostgreSQL memakai penguncian baris dan tingkat isolasi untuk mencegah dua transaksi membaca stok 1, lalu sama-sama menguranginya jadi 0, sehingga satu unit terjual dua kali (oversell). Inilah masalah yang tidak bisa diselesaikan rapi di layer aplikasi sendirian, dan sebab utama uang serta inventory menuntut database yang benar-benar ACID.

Relasional kuat, fitur modern tetap ada

PostgreSQL cocok untuk online shop karena kebutuhan e-commerce adalah campuran integritas transaksi, query relasional, pencarian produk, dan data semi-terstruktur dalam satu sistem.

JSON tanpa mengorbankan relasi

PostgreSQL mendukung json dan jsonb. Ini berguna untuk data yang strukturnya bervariasi, misalnya payload mentah dari provider pembayaran atau atribut bahan produk yang berbeda-beda per produk. Tetapi jangan menjadikannya alasan membuang relasi inti seperti orders, order_items, dan product_variants. Pakai jsonb untuk yang memang menyatu dan jarang di-query silang.

migrations/000006_create_payments.up.sql (potongan payments)Salin
CREATE TABLE payments (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id    bigint NOT NULL REFERENCES orders (id) ON DELETE CASCADE,
  provider    text   NOT NULL,
  status      text   NOT NULL DEFAULT 'pending'
                CHECK (status IN ('pending','paid','failed','expired','refunded')),
  amount_rupiah bigint NOT NULL CHECK (amount_rupiah >= 0),
  raw_payload jsonb  NOT NULL DEFAULT '{}',
  paid_at     timestamptz,
  created_at  timestamptz NOT NULL DEFAULT now()
);

Perhatikan keseimbangannya: order_id, status, dan amount_rupiah tetap kolom relasional yang bisa di-join, di-CHECK, dan di-index. Hanya raw_payload, yang bentuknya berbeda tiap provider dan jarang di-query per-field, yang disimpan sebagai jsonb. Ini paduan yang sulit didapat di database yang murni dokumen atau murni relasional.

Full-text search untuk katalog

Untuk versi awal, pencarian produk cukup memakai ILIKE '%serum%'. Saat katalog membesar, PostgreSQL punya full-text search dengan tsvector, tsquery, dan index GIN, memberi jalur bertahap sebelum kamu benar-benar butuh search engine terpisah seperti Elasticsearch. Kamu tidak harus pindah sistem hanya untuk pencarian yang lebih baik.

Latihan membaca desain, bukan menghafal semua SQL

Latihan ini membangun skema minimal yang menjadi fondasi modul SQL dasar, pgxpool, transaksi, dan repository di Roadmap 3. Tujuannya membaca maksud desain, bukan menghafal sintaks.

migrations/000001_create_core.up.sqlSalin
CREATE TABLE users (
  id            bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name          text NOT NULL,
  email         text NOT NULL UNIQUE,
  password_hash text NOT NULL,
  role          text NOT NULL DEFAULT 'customer'
                  CHECK (role IN ('customer', 'admin')),
  created_at    timestamptz NOT NULL DEFAULT now(),
  updated_at    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE products (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  slug        text NOT NULL UNIQUE,
  name        text NOT NULL,
  description text NOT NULL DEFAULT '',
  status      text NOT NULL DEFAULT 'draft'
                CHECK (status IN ('draft', 'active', 'archived')),
  created_at  timestamptz NOT NULL DEFAULT now(),
  updated_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE product_variants (
  id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  product_id   bigint NOT NULL REFERENCES products (id) ON DELETE CASCADE,
  sku          text   NOT NULL UNIQUE,
  variant_name text   NOT NULL,
  size_label   text,
  price_rupiah bigint NOT NULL CHECK (price_rupiah >= 0),
  is_active    boolean NOT NULL DEFAULT true,
  created_at   timestamptz NOT NULL DEFAULT now(),
  updated_at   timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id              bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id         bigint NOT NULL REFERENCES users (id) ON DELETE RESTRICT,
  order_number    text   NOT NULL UNIQUE,
  idempotency_key text   NOT NULL UNIQUE,
  status          text   NOT NULL DEFAULT 'pending'
                    CHECK (status IN ('pending','paid','processing','shipped',
                                      'completed','cancelled','refunded')),
  subtotal_rupiah bigint NOT NULL CHECK (subtotal_rupiah >= 0),
  total_rupiah    bigint NOT NULL CHECK (total_rupiah >= 0),
  created_at      timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE order_items (
  id                bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  order_id          bigint NOT NULL REFERENCES orders (id) ON DELETE CASCADE,
  variant_id        bigint NOT NULL REFERENCES product_variants (id) ON DELETE RESTRICT,
  product_name      text   NOT NULL,
  sku               text   NOT NULL,
  unit_price_rupiah bigint NOT NULL CHECK (unit_price_rupiah >= 0),
  quantity          integer NOT NULL CHECK (quantity > 0),
  created_at        timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX orders_user_id_created_at_idx ON orders (user_id, created_at DESC);
CREATE INDEX order_items_order_id_idx ON order_items (order_id);
CREATE INDEX product_variants_product_id_idx ON product_variants (product_id);

Setelah file ini ada, modul berikutnya mulai masuk ke SQL dasar: SELECT, INSERT, UPDATE, DELETE, JOIN, filter, sort, dan pagination. Baru setelah itu Go memakai pgx untuk menjalankan query dengan context.Context, dan repository menerjemahkan method seperti FindVariantByID(ctx, id) menjadi query yang aman.

Masalah database sering menyamar sebagai masalah kode

Banyak bug backend bukan berasal dari sintaks SQL, melainkan dari asumsi yang terlalu longgar tentang identitas, relasi, constraint, snapshot, dan index.

Fondasi data untuk seluruh Roadmap 3

Basis data relasional adalah fondasi proyek skincare, karena API yang baik tetap bergantung pada data yang konsisten, terhubung, dan dapat dicari.

Di peta proyek, modul ini menjadi dasar sebelum kita menulis SQL nyata. Setelah ini kita membaca dan menulis data dengan SELECT, INSERT, UPDATE, DELETE, lalu menghubungkannya ke Go lewat pgx dan pgxpool, membungkus checkout dalam transaksi, dan merapikannya menjadi repository. Fondasi yang benar di sini membuat repository, transaksi checkout, dan testing integrasi di Roadmap 3 sampai 6 jauh lebih bersih.