Kenapa penting

Kemampuan teknis yang kamu bangun dari M01 sampai M15 baru terlihat bila orang lain bisa melihat dan memahaminya. Perekrut tidak membaca semua kode kamu; mereka membaca README, CV, dan cara kamu menjelaskan keputusan di ruang wawancara. Bab ini mengubah capstone menjadi portofolio, memetakan tahapan interview backend, memberi kerangka menjawab system design, dan menutup jalur ini dengan rencana belajar berikutnya. Anggap ini sebagai "deploy ke production" untuk karier kamu.

Konsep inti

Portofolio: capstone sebagai etalase

Repo capstone adalah bukti terkuat yang kamu punya. Pewawancara biasanya hanya meluangkan 2–5 menit, jadi halaman depan repo harus menjawab tiga pertanyaan: ini apa, bagaimana arsitekturnya, dan bagaimana menjalankannya.

Bagian README	Isi minimum
Judul + ringkasan satu kalimat	Masalah apa yang diselesaikan
Badge	Status CI (GitHub Actions), opsional coverage
Diagram arsitektur	Service, database per service, broker, gateway — gambar atau teks
Cara menjalankan	Satu perintah: docker compose up atau kind + manifest
Cara menguji	./mvnw verify, contoh curl, hasil load test
Keputusan teknis	Kenapa outbox, kenapa Kafka, kenapa database per service — tautkan ke ADR
Batasan & rencana	Apa yang belum dikerjakan dan kenapa

Contoh kerangka README:

# Toko Jalur — e-commerce microservices
[![CI](https://github.com/<user>/toko-jalur/actions/workflows/ci.yml/badge.svg)](...)

Checkout dengan stok konsisten lintas service memakai outbox + Kafka.

## Arsitektur
gateway -> order-service (PostgreSQL) --outbox--> Kafka --> inventory-service (PostgreSQL)
                                                        \-> payment-service (PostgreSQL)

## Menjalankan
docker compose up -d   # atau: kind create cluster && kubectl apply -k k8s/

## Test
./mvnw verify          # unit + integrasi (Testcontainers)
k6 run load/checkout.js  # p95 180 ms @ 200 RPS

## Keputusan teknis
- ADR-001 Database per service
- ADR-002 Transactional outbox, bukan dual write

Commit history juga dibaca

Pesan commit yang jelas, branch yang rapi, dan PR berisi deskripsi menunjukkan cara kamu bekerja dalam tim. Hindari satu commit raksasa bernama update.

CV dan cara menjelaskan proyek

Daftar teknologi bukan pencapaian. Tulis setiap proyek dengan pola aksi + keputusan + hasil terukur. Angka dari load test, jumlah test, atau waktu build sudah cukup — kamu tidak perlu angka bisnis untuk proyek pribadi.

Saat diminta "ceritakan proyekmu", pakai urutan yang sama dengan README: masalah → arsitektur singkat → satu keputusan sulit → apa yang kamu pelajari. Siapkan jawaban untuk pertanyaan lanjutan yang hampir pasti muncul: "Kenapa tidak monolit saja?", "Apa yang terjadi bila Kafka mati?", "Bagaimana kamu tahu sistemnya sehat di production?". Jawaban jujur seperti "untuk skala ini monolit modular sebenarnya cukup; saya memilih microservices untuk belajar pola integrasinya" justru menunjukkan kedewasaan teknis.

Tahapan interview backend

Tahap	Yang diuji	Bekal dari jalur ini
Screening HR	Motivasi, komunikasi, ekspektasi	Cerita proyek singkat
Coding / DSA dasar	Array, string, Map, Set, sorting, Big-O	M03 collections & kompleksitas
Java deep-dive	equals/hashCode, immutability, concurrency, GC, stream	M02–M03, level Intermediate & Advanced
Spring deep-dive	DI, transaksi, JPA (N+1, lazy loading), security	Level Spring Boot
SQL	JOIN, GROUP BY, index, isolation level	Bab database & JPA
System design	Arsitektur, skala, trade-off	M13–M15
Behavioral / tim	Konflik, kegagalan, kolaborasi	Pengalaman code review & proyek

Untuk tahap coding, pewawancara backend jarang meminta algoritma eksotis. Yang sering muncul: menghitung frekuensi dengan Map, mencari duplikat dengan Set, menggabungkan interval, atau memvalidasi kurung dengan Deque. Biasakan menyebut kompleksitas sebelum ditanya: "solusi loop ganda ini O(n²); dengan HashMap jadi O(n) waktu dan O(n) memori."

Kerangka menjawab system design

Soal system design sengaja dibuat terbuka. Yang dinilai adalah proses berpikir, bukan diagram yang "benar". Pakai tujuh langkah ini dan katakan dengan lantang langkah mana yang sedang kamu kerjakan.

1. Requirement — fitur inti (fungsional) dan target skala, latensi, ketersediaan, konsistensi (non-fungsional). Sepakati apa yang tidak dikerjakan.
2. Estimasi — hitungan kasar: request per detik, rasio baca:tulis, ukuran data selama bertahun-tahun.
3. API — endpoint utama beserta request/response.
4. Data — entitas, skema, pilihan database, kunci pencarian.
5. Arsitektur — komponen dan alur request dari klien sampai database.
6. Bottleneck — titik yang pertama kali jebol saat beban naik dan cara mengatasinya (cache, replika baca, partisi, queue).
7. Trade-off — apa yang kamu korbankan dan kenapa (konsistensi vs ketersediaan, biaya vs latensi).

Estimasi cukup kasar

Satu bulan ≈ 2,6 juta detik; satu hari ≈ 86.400 detik. Bulatkan dengan berani — urutan besarnya yang penting, bukan digit terakhir.

Code review dan kerja tim

Di tim, kode kamu akan dibaca jauh lebih sering daripada ditulis. Saat membuat PR: kecil dan fokus, deskripsi menjelaskan kenapa, sertakan test, dan tandai bagian yang ingin kamu dapat masukan. Saat me-review: cek kebenaran logika dan edge case dulu, lalu keamanan dan performa, baru gaya penulisan. Tulis komentar sebagai pertanyaan atau saran dengan alasan ("Bagaimana kalau orderId null di sini? Mungkin perlu validasi di controller"), bukan perintah. Bedakan komentar yang memblokir merge dan yang sekadar opsional.

Take-home test

Take-home menilai cara kamu bekerja tanpa diawasi. Prioritasnya: requirement terpenuhi → kode terbaca → test bermakna (terutama untuk aturan bisnis) → README berisi cara menjalankan, asumsi, dan apa yang akan kamu tambahkan bila punya waktu lebih. Jangan menambah Kafka atau Kubernetes ke soal CRUD sederhana; justru tunjukkan bahwa kamu bisa memilih solusi paling sederhana yang memenuhi kebutuhan. Bila ada yang ambigu, tanyakan atau tulis asumsimu secara eksplisit.

Rencana belajar lanjut

Jalur ini memberi fondasi; teknologi berikutnya sebaiknya dipilih sesuai kebutuhan pekerjaan, bukan semuanya sekaligus.

Topik	Kapan berguna
Kotlin	Banyak tim JVM (terutama Android dan sebagian backend) memakainya; interop penuh dengan Java dan Spring
Spring WebFlux / reaktif	Streaming atau I/O sangat tinggi; untuk kebanyakan kasus, virtual thread sudah cukup
GraalVM Native Image	Startup cepat dan memori kecil (serverless, CLI) dengan biaya build lebih lama dan batasan refleksi
Sertifikasi cloud (AWS/GCP/Azure tingkat associate)	Memperdalam layanan terkelola: database, queue, IAM, jaringan
Pemrograman sistem & internal JVM	Tuning GC, profiling (JFR), memahami memory model lebih dalam

Contoh di dunia backend

Berikut contoh jawaban ringkas untuk soal klasik "Rancang URL shortener" mengikuti tujuh langkah.

1. Requirement. Fungsional: membuat short link dari URL panjang, redirect ke URL asli, link boleh punya masa berlaku. Non-fungsional: redirect cepat (p99 < 50 ms), ketersediaan tinggi, short code tidak boleh bentrok. Di luar scope: analitik detail dan akun pengguna.

2. Estimasi. Asumsikan 100 juta URL baru per bulan dan rasio baca:tulis 100:1. Hitungannya bisa kamu buktikan dengan Java biasa:

public class ShortCode {
    private static final String ALPHABET =
            "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";

    static String encode(long id) {
        if (id < 0) throw new IllegalArgumentException("id negatif: " + id);
        if (id == 0) return "0";
        StringBuilder sb = new StringBuilder();
        while (id > 0) {
            sb.append(ALPHABET.charAt((int) (id % 62)));
            id /= 62;
        }
        return sb.reverse().toString();
    }

    public static void main(String[] args) {
        System.out.println("id 125        -> " + encode(125));
        System.out.println("id 1000000000 -> " + encode(1_000_000_000L));

        // Estimasi kasar (back-of-the-envelope)
        long perMonth = 100_000_000L;              // 100 juta URL baru per bulan
        long writesPerSec = perMonth / (30L * 24 * 3600);
        long readsPerSec = writesPerSec * 100;     // rasio baca:tulis 100:1
        long tenYears = perMonth * 12 * 10;
        long capacity7 = (long) Math.pow(62, 7);
        System.out.println("tulis/detik   : " + writesPerSec);
        System.out.println("baca/detik    : " + readsPerSec);
        System.out.println("URL 10 tahun  : " + tenYears);
        System.out.println("kapasitas 62^7: " + capacity7);
        System.out.println("cukup?        : " + (capacity7 > tenYears));
    }
}

Output:

id 125        -> 21
id 1000000000 -> 15FTGg
tulis/detik   : 38
baca/detik    : 3800
URL 10 tahun  : 12000000000
kapasitas 62^7: 3521614606208
cukup?        : true

Kesimpulan estimasi: beban tulis kecil (~40/detik), beban baca jauh lebih besar (~4.000/detik, puncaknya mungkin beberapa kali lipat), dan kode basis 62 sepanjang 7 karakter cukup untuk 12 miliar URL.

3. API.

POST /api/v1/links        {"url": "https://...", "expiresAt": "2027-01-01T00:00:00Z"}
                          -> 201 {"code": "15FTGg", "shortUrl": "https://jlr.id/15FTGg"}
GET  /{code}              -> 302 Location: https://...   (404 bila tidak ada / kedaluwarsa)

4. Data. Satu tabel dengan pencarian berdasarkan code — pola akses key-value murni.

CREATE TABLE links (
    id          BIGINT PRIMARY KEY,
    code        VARCHAR(10) NOT NULL UNIQUE,
    target_url  TEXT        NOT NULL,
    expires_at  TIMESTAMPTZ,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

5. Arsitektur. Klien → load balancer → link-service (stateless, beberapa replika di Kubernetes) → cache Redis → PostgreSQL. ID unik dibuat oleh sequence database atau generator ID terdistribusi, lalu di-encode ke basis 62 — tidak perlu cek bentrok karena ID-nya sendiri unik.

6. Bottleneck. Redirect adalah hot path: pakai cache-aside di Redis dengan TTL, karena satu link populer bisa dibaca jutaan kali. Bila database baca menjadi beban, tambahkan replika baca. Sequence tunggal bisa jadi titik tunggal; alternatifnya alokasi blok ID per instance.

7. Trade-off. Kode berurutan mudah ditebak (orang bisa menelusuri link lain); bila itu masalah, acak ID sebelum di-encode dengan biaya kompleksitas tambahan. 302 memungkinkan analitik dan perubahan target, sedangkan 301 di-cache browser sehingga lebih hemat beban tetapi sulit diubah.

Kerangka yang sama berlaku untuk sistem pemesanan: requirement utamanya adalah kursi tidak boleh terjual dua kali, sehingga diskusinya berpusat pada reservasi sementara dengan batas waktu, constraint unik atau optimistic locking di database, dan idempotency key pada pembayaran — pola yang sudah kamu latih di capstone.

Pertanyaan interview

1. Bagaimana kamu menjelaskan proyek capstone dalam dua menit?

Mulai dari masalahnya (checkout e-commerce dengan stok yang konsisten), lalu arsitektur singkat (beberapa service, database per service, Kafka), satu keputusan sulit beserta alasannya (outbox untuk menghindari dual write), hasil terukur (latensi dari load test), dan satu hal yang akan kamu lakukan berbeda. Hindari membaca daftar teknologi.

2. Kapan kamu tidak memilih microservices?

Saat tim kecil, domain belum stabil, atau skala belum menuntutnya. Microservices menambah biaya operasional: jaringan yang bisa gagal, konsistensi eventual, observability terdistribusi, dan deployment yang lebih rumit. Monolit modular dengan batas modul yang jelas sering menjadi titik awal yang lebih baik dan bisa dipecah belakangan.

3. Bagaimana mencegah kursi terjual dua kali pada sistem pemesanan?

Jadikan database sebagai penjaga terakhir: constraint unik pada pasangan acara dan kursi, atau optimistic locking dengan kolom versi, sehingga transaksi kedua gagal secara eksplisit. Tambahkan reservasi sementara dengan masa berlaku agar kursi tidak terkunci selamanya, dan idempotency key pada pembayaran agar retry tidak membuat tagihan ganda.

Jebakan umum

• README kosong atau hanya bawaan generator — pewawancara menyerah sebelum melihat kodenya.
• Langsung menggambar arsitektur di soal system design tanpa mengklarifikasi requirement dan skala.
• CV berisi deretan teknologi tanpa konteks, keputusan, atau hasil yang terukur.
• Over-engineering take-home test dengan Kafka dan Kubernetes untuk soal CRUD sederhana.
• Membela kode secara personal saat code review alih-alih mendiskusikan alasan teknisnya.
• Mengaku menguasai teknologi yang hanya pernah dicoba sekilas — pertanyaan lanjutan akan membongkarnya.

Ringkasan

• Capstone di GitHub dengan README, diagram, cara menjalankan, test, dan CI badge adalah bukti kemampuan terkuat kamu.
• Tulis proyek di CV dengan pola aksi + keputusan teknis + hasil terukur.
• Interview backend umumnya mencakup coding/DSA dasar, deep-dive Java & Spring, SQL, system design, dan behavioral.
• Jawab system design dengan urutan requirement → estimasi → API → data → arsitektur → bottleneck → trade-off.
• Code review dan take-home menilai kebiasaan kerja: PR kecil, alasan yang jelas, test bermakna, solusi sesederhana mungkin.
• Pilih topik lanjutan (Kotlin, WebFlux, GraalVM native, sertifikasi cloud) sesuai kebutuhan pekerjaan.

Bacaan lanjutan

• Learn Java — dev.java
• Adding a workflow status badge — GitHub Docs
• GraalVM Native Image Support — Spring Boot