Take-Home Assignment

Format Umum

• Durasi: 3-7 hari
• Scope: API + database schema + tests + README
• Ekspektasi: Production-quality code dalam skala kecil

Yang Bikin Lolos vs Gak Lolos

Bikin Lolos

• README yang jelas: cara run, tech decision, trade-off
• Tests buat happy path + edge case
• Error handling yang proper (bukan cuma panic atau log.Fatal)
• Code structure yang clean (bukan semua di main.go)
• Database migration (bukan auto-migrate)
• Logging + tracing (walaupun sederhana)

Bikin Gagal

• Gak ada README atau README cuma 2 baris
• Gak ada tests ("saya gak sempat nulis test")
• Error handling cuma return err tanpa context
• Hardcode config (DB URL, port, secret)
• Commit message "fix", "update", "wip"

Struktur Project Go yang Direkomendasikan

project/
├── cmd/
│   └── server/
│       └── main.go          # entry point, wiring dependencies
├── internal/
│   ├── handler/             # HTTP handlers (thin layer)
│   │   ├── payment.go
│   │   └── payment_test.go
│   ├── service/             # business logic
│   │   ├── payment.go
│   │   └── payment_test.go
│   ├── repository/          # data access
│   │   ├── payment.go
│   │   └── payment_test.go
│   ├── model/               # domain types
│   │   └── payment.go
│   └── middleware/           # auth, logging, rate limit
│       └── ratelimit.go
├── migrations/              # database migrations
│   └── 001_create_payments.sql
├── docker-compose.yml       # infra dependencies
├── Makefile                 # run, test, migrate
└── README.md                # DOCUMENTASI KEPUTUSAN

README Template

# Payment Service — Take-Home Assignment

## Cara Run
```bash
docker-compose up -d    # Start PostgreSQL + Redis
make migrate            # Run database migrations
make run                # Start server on :8080

API

POST /api/v1/payments — Create payment GET /api/v1/payments/:id — Get payment status

Technical Decisions

Kenapa PostgreSQL bukan MySQL?

PostgreSQL punya advisory lock + SKIP LOCKED untuk queue processing. Ini kritis buat mencegah double-processing payment.

Kenapa Redis buat idempotency key?

TTL built-in, atomic SET NX, dan latency <1ms. Database bisa, tapi Redis lebih cocok buat caching short-lived state.

Kenapa structured logging (slog)?

Debug payment issue butuh tracing. Slog structured + context propagation lebih gampang di-debug dibanding fmt.Println.

Trade-offs

• Saat ini idempotency key disimpan di Redis (bukan DB). Pros: fast. Cons: kalau Redis down, idempotency check gagal.
• Solusi: fallback ke database query untuk idempotency check kalau Redis unreachable.

Kalau Ada Waktu Lebih

• Circuit breaker untuk downstream service
• Retry dengan exponential backoff
• Metrics + Prometheus endpoint
• Graceful shutdown dengan drain in-flight requests

## Checklist Sebelum Submit

- [ ] `docker-compose up` langsung jalan tanpa error
- [ ] README jelas, ada trade-off discussion
- [ ] Ada unit test + integration test
- [ ] Error message informatif (bukan "an error occurred")
- [ ] Config via environment variable, bukan hardcode
- [ ] Database migration, bukan auto-migrate
- [ ] Health check endpoint (`/health`)
- [ ] `.gitignore` — gak commit binary, `.env`, IDE files
- [ ] Commit history bersih (squash sebelum submit)
- [ ] Run `go vet` dan `golangci-lint` — zero warning