Logging Strategy yang Observable
Backend yang Bisa Ditelusuri

Log bukan catatan yang asal tampil, log adalah alat investigasi ketika sistem hidup.

Developer React membaca error dari browser console, developer Laravel membuka storage/logs/laravel.log, tetapi backend Go di production butuh log yang bisa ditelusuri lintas request, lintas service, dan lintas jam.

Pada online shop skincare, masalah yang paling mahal jarang muncul sebagai crash yang jelas. Checkout gagal karena stok berubah di detik terakhir, webhook pembayaran datang dua kali, atau customer service menelepon menanyakan order yang statusnya tertahan di pending sejak pagi. Tanpa log yang rapi, kita cuma punya dugaan dan tangkapan layar buram dari pelanggan.

Tujuan chapter ini bukan membuat log sebanyak-banyaknya. Tujuannya membuat log yang menjawab pertanyaan production dengan satu query: request mana yang gagal, user mana yang terdampak, order mana yang bermasalah, di tahap apa kegagalannya, dan berapa lama operasi itu berjalan. Itulah arti “men-debug masalah production lebih mudah”.

Bedanya bukan soal tampilan, tetapi soal bagaimana log dicari oleh manusia dan mesin.

String log mudah ditulis tetapi sulit dicari dengan akurat. Structured log menulis event sebagai pasangan key-value, sehingga sistem log bisa memfilter level, request_id, user_id, atau order_id tanpa regex yang rapuh.

Bayangkan tiga ribu baris log dari ratusan checkout bercampur dalam satu menit di production. Dengan string log, kamu menelusuri dengan grep dan berharap format pesannya konsisten. Dengan structured log, kamu menulis satu query order_id = 1001 AND level = "ERROR" dan langsung mendapat semua kegagalan untuk order itu, terurut waktu.

String log: mudah ditulis, sulit di-querySalin
2026/06/06 10:15:43 checkout failed for user 42 order 1001 payment timeout

Structured log: setiap konteks jadi fieldSalin
{
  "time": "2026-06-06T10:15:43.512Z",
  "level": "ERROR",
  "msg": "checkout failed",
  "service": "skincare-api",
  "env": "production",
  "request_id": "req_8f2c1a4d",
  "user_id": 42,
  "order_id": 1001,
  "stage": "authorize_payment",
  "error": "payment gateway timeout"
}

Logging adalah cross-cutting concern, ia menembus semua layer tetapi punya aturan main.

Di Chapter 1 sampai 4 kamu sudah menata handler, service, repository, config, dan error. Logging adalah lapis yang berbeda sifatnya: ia menembus semuanya. Justru karena itu, ia butuh aturan agar tidak berubah jadi kebisingan.

Aturan mainnya sederhana: middleware HTTP mencatat satu access log per request, service mencatat event bisnis dan kegagalan di boundary yang punya konteks, repository umumnya tidak melog (ia mengembalikan error ke atas), dan error yang sama tidak dilog dua kali di layer berbeda.

flowchart TD
  FE["React Storefront"] -->|HTTP JSON| MW["httpmw: RequestID + AccessLog"]
  MW -->|"context: request_id + logger"| H["chi Handler"]
  H -->|"FromContext(ctx)"| S["Order Service"]
  S --> R["Repository (pgx)"]
  R --> DB[("PostgreSQL")]
  MW -. "1 access log / request" .-> OUT[("stdout JSON")]
  S -. "business log + error log" .-> OUT
  R -. "tidak melog, kembalikan error" .-> S

Gambar 1. Logging menembus semua layer, tetapi dengan pembagian kerja: middleware menulis access log, service menulis business log dan error log, repository hanya mengembalikan error ke atas. Semua mengalir ke stdout sebagai JSON.

Go sudah punya structured logging di standard library sejak Go 1.21, dan ia matang di seri 1.26.

Paket log/slog adalah pilihan default yang aman untuk memulai: structured logging dengan level, message, dan attribute, tanpa membawa satu pun dependency eksternal.

Paket resmi log/slog menyediakan tiga lapis konsep: Logger (API yang kamu panggil), Handler (yang memutuskan format dan tujuan output), dan Attr (pasangan key-value). Untuk production kita pakai slog.NewJSONHandler yang menulis JSON ke os.Stdout. Di container dan AWS, pola standarnya adalah aplikasi menulis ke stdout, lalu platform (ECS, CloudWatch) yang mengumpulkan dan menyimpan log itu.

internal/logging/logger.goSalin
package logging

import (
	"log/slog"
	"os"
	"strings"
)

// Config diisi dari Chapter 3 (Configuration Management).
type Config struct {
	Env      string // "local", "staging", "production"
	LogLevel string // "debug", "info", "warn", "error"
}

// NewLogger membangun satu logger proses, dipasang sekali saat startup.
func NewLogger(cfg Config) *slog.Logger {
	// LevelVar bisa diubah saat runtime tanpa membuat handler baru.
	level := new(slog.LevelVar)
	level.Set(parseLevel(cfg.LogLevel))

	var handler slog.Handler
	opts := &slog.HandlerOptions{
		Level: level,
		// AddSource menambah file:line. Berguna di lokal, mahal di production.
		AddSource: cfg.Env != "production",
	}

	if cfg.Env == "local" {
		// Lokal: teks ramah-mata di terminal.
		handler = slog.NewTextHandler(os.Stdout, opts)
	} else {
		// Staging/production: JSON untuk mesin (CloudWatch).
		handler = slog.NewJSONHandler(os.Stdout, opts)
	}

	// With menanam field tetap yang ikut di SETIAP log line proses ini.
	logger := slog.New(handler).With(
		slog.String("service", "skincare-api"),
		slog.String("env", cfg.Env),
	)

	// SetDefault agar slog.Info(...) global juga memakai handler ini,
	// termasuk log dari library yang memakai slog.Default().
	slog.SetDefault(logger)

	return logger
}

func parseLevel(s string) slog.Level {
	switch strings.ToLower(s) {
	case "debug":
		return slog.LevelDebug
	case "warn":
		return slog.LevelWarn
	case "error":
		return slog.LevelError
	default:
		return slog.LevelInfo
	}
}

Level menjawab seberapa penting, field menjawab konteksnya apa.

Structured log baru berguna kalau seluruh tim sepakat kapan memakai Debug, Info, Warn, dan Error. Tanpa kesepakatan, level jadi acak dan filter level = "ERROR" kehilangan arti.

slog punya empat level bawaan dengan nilai numerik (Debug = -4, Info = 0, Warn = 4, Error = 8). Handler hanya menulis log yang levelnya sama atau lebih tinggi dari Level yang dipasang. Karena kita memakai slog.LevelVar, ambang ini bisa kamu naik-turunkan tanpa restart, misalnya menurunkan ke Debug sementara saat sedang menyelidiki insiden, lalu menaikkan lagi ke Info.

Field yang konsisten lebih penting daripada pesan yang puitis. Untuk API skincare, kosakata field minimum yang sering dipakai adalah request_id, method, path, status, duration_ms, user_id, order_id, variant_id, stage, dan error. Sepakati nama-nama ini sekali, lalu pakai persis sama di mana pun.

internal/order/service.goSalin
// Event normal: pakai Info. Field bisnis sebagai Attr.
logger.InfoContext(ctx, "checkout completed",
	slog.Int64("user_id", userID),
	slog.Int64("order_id", order.ID),
	slog.Int64("total_rupiah", order.TotalRupiah),
	slog.Int("item_count", len(items)),
)

// Kondisi tidak ideal tapi belum gagal: pakai Warn.
logger.WarnContext(ctx, "inventory is low",
	slog.Int64("variant_id", variantID),
	slog.Int("remaining_stock", remainingStock),
)

// Operasi gagal: pakai Error, sertakan stage dan error.
logger.ErrorContext(ctx, "checkout failed",
	slog.Int64("user_id", userID),
	slog.String("stage", "reserve_inventory"),
	slog.String("error", err.Error()),
)

Satu request checkout melewati handler, service, repository, dan payment client. Request ID adalah benang merahnya.

Tanpa request ID, log dari ratusan pelanggan bercampur jadi satu. Dengan request ID, kamu bisa menarik semua event satu request checkout: dari POST /v1/orders, validasi cart, pengurangan stok, otorisasi pembayaran, sampai response akhir, lalu membacanya berurutan.

Kita membuat middleware chi yang membaca header X-Request-ID dari client (kalau ada, misalnya dari API gateway), atau membangkitkan satu yang baru, lalu menyimpannya di context.Context dan menempelkannya di response. chi v5 punya middleware.RequestID bawaan, tetapi membuat sendiri membuat kamu paham persis apa yang terjadi dan bebas memilih format ID-nya.

sequenceDiagram
  participant FE as React Client
  participant MW as RequestID Middleware
  participant H as Order Handler
  participant S as Checkout Service
  participant DB as PostgreSQL
  FE->>MW: POST /v1/orders
  MW->>MW: baca atau buat X-Request-ID
  MW->>H: ctx + request_id
  H->>S: Checkout(ctx, userID)
  S->>DB: reserve stock, insert order
  S-->>H: order result
  H-->>FE: 201 Created (header X-Request-ID)

Gambar 2. request_id lahir di middleware, ikut mengalir lewat context.Context ke setiap layer, dan dipantulkan kembali ke client lewat header response.

internal/httpmw/request_id.goSalin
package httpmw

import (
	"context"
	"crypto/rand"
	"encoding/hex"
	"net/http"
)

const requestIDHeader = "X-Request-ID"

// contextKey unexported agar tidak bentrok dengan key package lain.
type requestIDContextKey struct{}

// RequestID membaca atau membangkitkan request_id, lalu menaruhnya di context.
func RequestID(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		requestID := r.Header.Get(requestIDHeader)
		if requestID == "" {
			requestID = newRequestID()
		}

		// Pantulkan ke client agar frontend bisa menyimpan/menampilkannya.
		w.Header().Set(requestIDHeader, requestID)

		ctx := context.WithValue(r.Context(), requestIDContextKey{}, requestID)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

// RequestIDFromContext mengambil request_id; aman dipanggil di layer mana pun.
func RequestIDFromContext(ctx context.Context) string {
	requestID, ok := ctx.Value(requestIDContextKey{}).(string)
	if !ok {
		return ""
	}

	return requestID
}

func newRequestID() string {
	var b [8]byte
	if _, err := rand.Read(b[:]); err != nil {
		return "req_unknown"
	}

	return "req_" + hex.EncodeToString(b[:])
}

Daripada mengoper request_id dan user_id ke setiap pemanggilan log, tanam logger ber-konteks sekali.

Kita bisa mengoper request_id ke setiap logger.Info(...), tetapi itu berulang dan mudah lupa. Cara yang lebih bersih: simpan satu *slog.Logger yang sudah membawa field request di dalam context.Context, lalu setiap layer mengambilnya dengan FromContext(ctx).

Logger yang sudah diperkaya dengan With(slog.String("request_id", ...)) akan menyertakan field itu di setiap log line, otomatis, tanpa pemanggil perlu mengingatnya. Saat auth middleware (dari Roadmap 2 / Roadmap 7) sudah menaruh user_id di context, kita perkaya logger dengan user_id juga, sehingga seluruh log untuk request itu langsung membawa siapa pelakunya.

internal/logging/context.goSalin
package logging

import (
	"context"
	"log/slog"
)

type loggerContextKey struct{}

// IntoContext menyimpan logger (yang sudah diperkaya) ke dalam context.
func IntoContext(ctx context.Context, logger *slog.Logger) context.Context {
	return context.WithValue(ctx, loggerContextKey{}, logger)
}

// FromContext mengambil logger ber-konteks; jatuh ke slog.Default() bila tak ada,
// sehingga aman dipanggil di mana pun tanpa takut nil pointer.
func FromContext(ctx context.Context) *slog.Logger {
	logger, ok := ctx.Value(loggerContextKey{}).(*slog.Logger)
	if !ok || logger == nil {
		return slog.Default()
	}

	return logger
}

Field user_id diperkaya di middleware autentikasi, setelah token diverifikasi. Polanya: ambil logger dari context, tambahkan user_id, lalu simpan kembali logger yang sudah diperkaya itu ke context untuk layer berikutnya.

internal/httpmw/enrich_user.goSalin
package httpmw

import (
	"log/slog"
	"net/http"

	"github.com/kamu/skincare-backend/internal/logging"
)

// EnrichUser dipasang SETELAH middleware auth menaruh user_id di context.
// Ia memperkaya logger ber-konteks dengan user_id agar ikut di semua log line.
//
// UserIDFromContext disediakan oleh middleware autentikasi (Roadmap 7) dan
// tinggal di package httpmw yang sama, jadi forward-reference ini akan tersedia
// begitu modul autentikasi terpasang.
func EnrichUser(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		ctx := r.Context()

		userID, ok := UserIDFromContext(ctx)
		if ok {
			logger := logging.FromContext(ctx).With(slog.Int64("user_id", userID))
			ctx = logging.IntoContext(ctx, logger)
		}

		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

Setiap request HTTP perlu satu log ringkas yang konsisten: siapa, ke mana, hasilnya apa, berapa lama.

Access log adalah satu baris per request yang mencatat metode, path, status, dan durasi. Ia juga tempat yang tepat untuk menanam logger ber-konteks (dengan request_id) ke context.Context, sehingga layer di bawahnya tinggal mengambilnya.

Di Go, middleware adalah fungsi yang membungkus http.Handler. Karena kita perlu tahu status code yang akhirnya ditulis handler, kita bungkus http.ResponseWriter dengan recorder kecil yang mengintip WriteHeader. Setelah handler selesai, kita hitung durasi dan tulis satu log dengan level yang sesuai status: Error untuk 5xx, Warn untuk 4xx, Info untuk sisanya.

internal/httpmw/access_log.goSalin
package httpmw

import (
	"log/slog"
	"net/http"
	"time"

	"github.com/kamu/skincare-backend/internal/logging"
)

// statusRecorder mengintip status code agar bisa dicatat di access log.
type statusRecorder struct {
	http.ResponseWriter
	status int
}

func (r *statusRecorder) WriteHeader(status int) {
	r.status = status
	r.ResponseWriter.WriteHeader(status)
}

// AccessLog menanam logger ber-konteks, menjalankan handler, lalu menulis 1 log.
func AccessLog(baseLogger *slog.Logger) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			startedAt := time.Now()
			requestID := RequestIDFromContext(r.Context())

			// Logger yang membawa request_id, method, path untuk SELURUH request.
			logger := baseLogger.With(
				slog.String("request_id", requestID),
				slog.String("method", r.Method),
				slog.String("path", r.URL.Path),
			)

			// Tanam ke context agar handler dan service mengambilnya.
			ctx := logging.IntoContext(r.Context(), logger)
			recorder := &statusRecorder{ResponseWriter: w, status: http.StatusOK}

			next.ServeHTTP(recorder, r.WithContext(ctx))

			attrs := []slog.Attr{
				slog.Int("status", recorder.status),
				slog.Int64("duration_ms", time.Since(startedAt).Milliseconds()),
			}

			switch {
			case recorder.status >= http.StatusInternalServerError:
				logger.LogAttrs(ctx, slog.LevelError, "http request failed", attrs...)
			case recorder.status >= http.StatusBadRequest:
				logger.LogAttrs(ctx, slog.LevelWarn, "http request client error", attrs...)
			default:
				logger.LogAttrs(ctx, slog.LevelInfo, "http request completed", attrs...)
			}
		})
	}
}

Urutan pemasangan middleware menentukan urutan eksekusi. RequestID harus jalan lebih dulu agar AccessLog bisa membaca request ID dari context. Wiring-nya disusun di cmd/api/main.go, menyatu dengan dependency injection dari Chapter sebelumnya.

cmd/api/main.goSalin
package main

import (
	"net/http"
	"os"
	"time"

	"github.com/go-chi/chi/v5"

	"github.com/kamu/skincare-backend/internal/httpmw"
	"github.com/kamu/skincare-backend/internal/logging"
)

func main() {
	// Config datang dari Chapter 3 (di sini disederhanakan).
	logger := logging.NewLogger(logging.Config{
		Env:      os.Getenv("APP_ENV"),
		LogLevel: os.Getenv("LOG_LEVEL"),
	})

	r := chi.NewRouter()
	r.Use(httpmw.RequestID)        // 1. buat request_id dulu
	r.Use(httpmw.AccessLog(logger)) // 2. baru access log bisa membacanya

	r.Get("/health", func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusOK)
		_, _ = w.Write([]byte("ok"))
	})

	logger.Info("api server starting", slog.String("addr", ":8080"))

	srv := &http.Server{
		Addr:              ":8080",
		Handler:           r,
		ReadHeaderTimeout: 5 * time.Second,
	}
	if err := srv.ListenAndServe(); err != nil {
		logger.Error("api server stopped", slog.String("error", err.Error()))
		os.Exit(1)
	}
}

Log error yang baik memberi tahu operasi apa yang gagal dan input bisnis mana yang relevan.

Pesan error mentah jarang cukup. payment timeout tidak memberi tahu order mana, user mana, atau di tahap apa kegagalan terjadi. Error context yang baik menjawab semua itu dalam satu log line.

Ingat dari Chapter 4: di Go, error adalah nilai. Repository mengembalikan error domain, service membungkusnya dengan fmt.Errorf("...: %w", err) untuk menambah jejak, dan logging dilakukan di boundary yang punya konteks bisnis cukup, bukan di setiap fungsi kecil. stage adalah field paling berharga di sini: ia memberi tahu di langkah mana checkout patah.

internal/order/service.goSalin
package order

import (
	"context"
	"fmt"
	"log/slog"
	"time"

	"github.com/kamu/skincare-backend/internal/logging"
)

type Service struct {
	repo  Repository
	pay   PaymentGateway
	clock func() time.Time
}

// Checkout melog di boundary service: satu Info saat sukses, satu Error per tahap gagal.
func (s *Service) Checkout(ctx context.Context, userID int64) (Order, error) {
	// Ambil logger ber-konteks; request_id dan user_id sudah menempel dari middleware.
	logger := logging.FromContext(ctx)

	cart, err := s.repo.GetActiveCart(ctx, userID)
	if err != nil {
		logger.ErrorContext(ctx, "checkout failed",
			slog.String("stage", "load_cart"),
			slog.String("error", err.Error()),
		)
		return Order{}, fmt.Errorf("load active cart: %w", err)
	}

	order, err := s.repo.CreateOrderFromCart(ctx, cart.ID, s.clock())
	if err != nil {
		logger.ErrorContext(ctx, "checkout failed",
			slog.String("stage", "create_order"),
			slog.Int64("cart_id", cart.ID),
			slog.String("error", err.Error()),
		)
		return Order{}, fmt.Errorf("create order from cart: %w", err)
	}

	if err := s.pay.Authorize(ctx, order.OrderNumber, order.TotalRupiah); err != nil {
		logger.ErrorContext(ctx, "checkout failed",
			slog.String("stage", "authorize_payment"),
			slog.Int64("order_id", order.ID),
			slog.String("order_number", order.OrderNumber),
			slog.String("error", err.Error()),
		)
		return Order{}, fmt.Errorf("authorize payment: %w", err)
	}

	logger.InfoContext(ctx, "checkout completed",
		slog.Int64("order_id", order.ID),
		slog.String("order_number", order.OrderNumber),
		slog.Int64("total_rupiah", order.TotalRupiah),
	)

	return order, nil
}

Log production sering bertahan berbulan-bulan dan dibaca banyak orang serta banyak sistem.

Logging yang baik bukan hanya lengkap, tetapi juga aman. Sekali rahasia masuk ke log, ia tersimpan di banyak tempat (CloudWatch, backup, indeks pencarian) dan sangat sulit dicabut. Pencegahan jauh lebih murah daripada pembersihan.

Untuk online shop skincare, jangan pernah menulis password, hash password yang tidak perlu, access token, refresh token, header Authorization, session cookie, nomor kartu lengkap (PAN), CVV, alamat lengkap bila tidak perlu, atau payload webhook mentah yang berisi secret provider. Log cukup ID referensi, status, dan metadata aman untuk tracing.

Cara paling rapuh adalah mengandalkan ingatan setiap developer untuk tidak melog rahasia. Cara idiomatik di slog adalah membuat rahasia itu mustahil dilog dengan benar: bungkus nilai sensitif dalam tipe yang mengimplementasikan slog.LogValuer, sehingga ia selalu mencetak REDACTED apa pun yang terjadi.

internal/logging/redact.goSalin
package logging

import "log/slog"

// Secret membungkus string sensitif (token, password, secret provider).
// Karena ia mengimplementasikan slog.LogValuer, slog TIDAK PERNAH
// mencetak nilai aslinya, bahkan jika developer lupa dan melognya.
type Secret string

// LogValue dipanggil slog saat hendak melog nilai bertipe Secret.
func (Secret) LogValue() slog.Value {
	return slog.StringValue("REDACTED")
}

// Card membungkus nomor kartu agar log hanya menampilkan 4 digit terakhir.
type Card string

func (c Card) LogValue() slog.Value {
	s := string(c)
	if len(s) < 4 {
		return slog.StringValue("****")
	}

	return slog.StringValue("****" + s[len(s)-4:])
}

Dengan tipe ini, sekali sebuah field dideklarasikan sebagai Secret, ia aman selamanya. Bahkan kalau developer yang sedang terburu-buru menulis logger.Info("debug", "token", token), output-nya tetap "token":"REDACTED".

contoh pemakaian Secret dan CardSalin
token := logging.Secret(rawAccessToken)
pan := logging.Card("4111111111111111")

logger.InfoContext(ctx, "payment attempt",
	slog.Int64("order_id", order.ID),
	slog.String("provider", "midtrans"),
	slog.Any("access_token", token), // -> "access_token":"REDACTED"
	slog.Any("card", pan),           // -> "card":"****1111"
)

Untuk pertahanan lapis kedua, HandlerOptions.ReplaceAttr bisa menyensor field berdasarkan key di seluruh aplikasi, jaring pengaman terakhir kalau ada rahasia yang lolos dengan key yang sudah dikenal seperti authorization atau password.

internal/logging/logger.go (tambahan ReplaceAttr)Salin
var sensitiveKeys = map[string]struct{}{
	"authorization": {},
	"password":      {},
	"access_token":  {},
	"refresh_token": {},
	"cookie":        {},
	"cvv":           {},
}

// redactSensitive dipasang sebagai HandlerOptions.ReplaceAttr.
func redactSensitive(groups []string, a slog.Attr) slog.Attr {
	if _, ok := sensitiveKeys[strings.ToLower(a.Key)]; ok {
		return slog.String(a.Key, "REDACTED")
	}

	return a
}

Kita rangkai request ID, access log, business log, dan redaksi pada satu endpoint checkout, lalu menelusurinya seperti di production.

Hands-on ini menyambungkan semua potongan: middleware, logger ber-konteks, business log, dan redaksi. Targetnya, satu request checkout menghasilkan jejak log yang bisa kamu tarik utuh hanya dengan satu request_id.

TerminalSalin
curl -i -X POST http://localhost:8080/v1/orders \
  -H "Content-Type: application/json" \
  -H "X-Request-ID: req_demo_checkout_001" \
  -H "Authorization: Bearer dummy-access-token" \
  -d '{"idempotency_key":"chk_2026_0606_42"}'

Di terminal, kamu akan melihat tepat dua baris log untuk request sukses: satu dari service (checkout completed) dan satu dari access log (http request completed). Keduanya membawa request_id yang sama. Perhatikan bahwa header Authorization tidak pernah muncul di log, karena ReplaceAttr dan tipe Secret menyensornya.

Log dari service: checkout completedSalin
{
  "time": "2026-06-06T10:15:43.418Z",
  "level": "INFO",
  "msg": "checkout completed",
  "service": "skincare-api",
  "env": "staging",
  "request_id": "req_demo_checkout_001",
  "method": "POST",
  "path": "/v1/orders",
  "user_id": 42,
  "order_id": 1001,
  "order_number": "SKN-2026-0606-1001",
  "total_rupiah": 249000
}

Log dari access log middleware: 1 baris per requestSalin
{
  "time": "2026-06-06T10:15:43.421Z",
  "level": "INFO",
  "msg": "http request completed",
  "service": "skincare-api",
  "env": "staging",
  "request_id": "req_demo_checkout_001",
  "method": "POST",
  "path": "/v1/orders",
  "user_id": 42,
  "status": 201,
  "duration_ms": 37
}

Sekarang skenario yang sebenarnya kita latih: checkout gagal di tahap pembayaran. Karena setiap kegagalan membawa stage, kamu langsung tahu titik patahnya tanpa membaca kode. Inilah alur men-debug masalah production yang menjadi tujuan chapter ini.

flowchart LR
  A["Pelanggan lapor:<br/>checkout gagal"] --> B["Frontend kirim<br/>X-Request-ID ke support"]
  B --> C["Query CloudWatch:<br/>request_id = req_..."]
  C --> D["Lihat field stage<br/>pada level ERROR"]
  D --> E["stage = authorize_payment<br/>error = gateway timeout"]
  E --> F["Akar masalah ketemu<br/>tanpa membaca kode"]

Gambar 3. Alur investigasi nyata. request_id menghubungkan keluhan pelanggan ke log, stage menunjuk tahap yang patah, dan error memberi sebabnya. Tiga field, satu query, akar masalah ketemu.

Log saat checkout gagal di pembayaranSalin
{
  "time": "2026-06-06T10:16:02.105Z",
  "level": "ERROR",
  "msg": "checkout failed",
  "service": "skincare-api",
  "env": "staging",
  "request_id": "req_demo_checkout_001",
  "method": "POST",
  "path": "/v1/orders",
  "user_id": 42,
  "stage": "authorize_payment",
  "order_id": 1001,
  "order_number": "SKN-2026-0606-1001",
  "error": "payment gateway timeout"
}

Logging yang observable membuat modular monolith skincare lebih mudah dirawat begitu masuk staging dan production: saat ada yang patah, kamu menelusuri, bukan menebak.

Setelah chapter ini, Roadmap 4 makin siap untuk production: arsitektur sudah berlapis, config sudah rapi, error sudah punya bentuk, dan logging sudah bisa menjawab apa yang terjadi pada satu request tertentu. Langkah berikutnya di Chapter 6 adalah memisahkan validasi input dari aturan bisnis (stok, produk aktif, voucher, transisi status order), lalu Chapter 7 membahas idempotency agar retry jaringan dan webhook ganda tidak menggandakan order. Lebih jauh, di Roadmap 8 logging JSON ini bertemu CloudWatch Logs Insights untuk observability penuh saat backend skincare berjalan di AWS.