Peta pengetahuan software architect dari ByteByteGo memuat sekitar lima puluh istilah dalam delapan area. Daftar sepanjang itu mudah diperlakukan sebagai kurikulum: selesaikan satu area, centang, lalu pindah ke area berikutnya. Padahal hampir tidak ada keputusan arsitektur yang hanya menyentuh satu area.
Saya memakai peta ini sebagai indeks, bukan urutan belajar. Nilainya baru terasa ketika setiap area dibaca bersama pertanyaan yang harus bisa dijawab, dan ketika beberapa labelnya yang terlalu ringkas diluruskan.
Delapan area dan pertanyaan di baliknya
Dua kolom pertama berasal dari peta. Kolom ketiga adalah pertanyaan keputusan yang menurut saya membuat area tersebut relevan bagi seorang architect.
Area | Isi peta | Pertanyaan keputusan |
Programming language | Java, Python, Go, JavaScript | Bagaimana model concurrency dan ekosistem bahasa memengaruhi cara tim membangun serta merawat sistem? |
Tools | GitHub, Jenkins, Jira, ELK, Sonar | Bagaimana perubahan dilacak, diuji, dan diamati setelah sampai di production? |
Design principles | OOP, clean code, TDD, DDD, CAP theorem, MVC, ACID, GoF patterns | Di mana batas domain, dan aturan data mana yang wajib selalu konsisten? |
Architectural principles | Microservices, publish-subscribe, layered, event-driven, client-server, hexagonal | Masalah apa yang diselesaikan sebuah pola, dan biaya operasional apa yang ikut dibawanya? |
Platform knowledge | Containers, orchestration, cloud, serverless, CDN, API gateway, distributed systems, CI/CD | Apa yang terjadi ketika satu komponen lambat, gagal, atau perlu diganti? |
Data analytics | SQL, NoSQL, data streaming, object storage, data migration, OLAP | Data mana yang menjadi source of truth, dan bagaimana skemanya berubah tanpa menghentikan layanan? |
Networking and security | DNS, TCP, TLS, HTTPS, encryption, JWT, OAuth, credential management | Siapa boleh mengakses apa, dan bagaimana kredensial dicabut bila bocor? |
Supporting skills | Decision-making, technology knowledge, stakeholder management, communication, estimation, leadership | Bagaimana keputusan dijelaskan, disepakati, dan ditinjau ulang? |
Label "Data analytics" sedikit menyesatkan. Isinya mencakup database transaksional dan data migration, yang termasuk pengelolaan data operasional, bukan hanya analitik. Untuk architect, bagian ini lebih tepat dibaca sebagai data management.
CAP theorem bukan label untuk memilih database
Peta menempatkan CAP theorem di design principles, bersebelahan dengan ACID. Ringkasan yang sering beredar adalah "pilih dua dari tiga": consistency, availability, atau partition tolerance. Eric Brewer, yang merumuskan CAP, menyebut formulasi itu menyesatkan dalam CAP Twelve Years Later. Pilihan antara consistency dan availability baru muncul ketika partition terjadi; di luar kondisi itu, sistem dapat memperoleh keduanya.
Artikel yang sama juga membedakan huruf C pada kedua istilah. C pada ACID berarti transaksi menjaga semua aturan database, seperti unique key. C pada CAP hanya berarti single-copy consistency, bagian kecil dari pengertian ACID. Mempelajari keduanya berdampingan tanpa pembedaan ini membuat diskusi desain mudah salah arah.
Martin Kleppmann melangkah lebih jauh dalam Please stop calling databases CP or AP: definisi dalam CAP terlalu sempit sehingga banyak database nyata tidak cocok dengan label CP maupun AP.
Pertanyaan yang lebih berguna bersifat per operasi. Ketika node tidak dapat saling menghubungi, operasi mana yang boleh tetap berjalan dengan data yang mungkin usang, dan operasi mana yang harus ditolak? Misalnya, daftar rekomendasi produk masih layak ditampilkan dari salinan lama, sedangkan pengurangan saldo tidak.
JWT di area keamanan adalah format, bukan jaminan
Di area networking and security, JWT berdiri sejajar dengan encryption dan OAuth. JWT sebenarnya format token. Keamanannya bergantung pada cara token diverifikasi, dan JWT yang hanya ditandatangani tetap dapat dibaca isinya oleh siapa pun yang memegangnya.
RFC 8725, JSON Web Token Best Current Practices, mencatat serangan yang memanfaatkan header
alg. Penyerang mengganti algoritma menjadi none sehingga library yang rentan menerima token tanpa memeriksa signature. Variasi lain mengganti algoritma RSA menjadi HMAC, sehingga public key RSA dipakai sebagai secret HMAC. Mitigasinya: library harus memungkinkan pemanggil menentukan daftar algoritma yang diizinkan, dan tidak boleh memakai algoritma di luar daftar tersebut.Di Node.js, library
jsonwebtoken versi 9 menyediakan opsi algorithms, issuer, dan audience pada jwt.verify:const jwt = require('jsonwebtoken')
const claims = jwt.verify(token, publicKey, {
algorithms: ['RS256'],
issuer: 'https://auth.example.com',
audience: 'orders-api',
})Memahami struktur JWT hanya separuh pekerjaan. Bagi architect, pertanyaan pentingnya ada di kolom ketiga tabel: bagaimana token yang bocor dicabut, berapa lama masa berlakunya, dan service mana yang benar-benar perlu menerimanya.
Yang tidak tertulis di peta: target kualitas
Peta menyebut ELK di area tools, tetapi tidak menyebut cara menentukan seberapa baik sistem harus bekerja. Tanpa target, trade-off tidak punya ukuran. Cache, redundansi, dan retry semuanya menambah kompleksitas; target menentukan apakah kompleksitas itu sepadan.
Bab Service Level Objectives dalam buku Site Reliability Engineering memberi kosakata yang tepat. SLI adalah ukuran kuantitatif kinerja layanan, seperti latency atau error rate. SLO adalah target untuk ukuran tersebut. Buku itu juga menegaskan bahwa menuntut SLO terpenuhi 100% sepanjang waktu tidak realistis dan tidak diinginkan.
Keputusan menambahkan retry menunjukkan bagaimana area-area di peta bertemu. Retry menyentuh platform (timeout dan load balancer), networking (perilaku HTTP), dan data (efek ganda pada database). RFC 9110 bagian 9.2.2 menyatakan bahwa client SHOULD NOT mengulang otomatis request dengan method non-idempotent, kecuali ada cara mengetahui bahwa request itu idempotent atau bahwa request awal belum diterapkan. Jadi retry pada
POST pembuatan pesanan membutuhkan desain tambahan, misalnya idempotency key yang disimpan di sisi server.Keputusan perlu jejak tertulis
Area supporting skills menyebut decision-making, tetapi keputusan yang hanya hidup dalam ingatan sulit ditinjau ulang. Michael Nygard mengusulkan Architecture Decision Record (ADR): satu file pendek per keputusan, disimpan di repository pada path seperti
doc/arch/adr-NNN.md, dengan bagian Title, Context, Decision, Status, dan Consequences. Keputusan yang dibatalkan tidak dihapus; statusnya diubah menjadi superseded dan merujuk keputusan penggantinya.Untuk keputusan retry di atas, ADR-nya dapat sesingkat ini:
# ADR 7: Retry otomatis hanya untuk request idempotent
## Context
Timeout antara API gateway dan layanan pesanan memicu retry. Retry pada
POST /orders dapat membuat pesanan ganda.
## Decision
Gateway hanya me-retry GET, PUT, dan DELETE. POST /orders menerima header
Idempotency-Key; server menyimpan key beserta hasilnya selama 24 jam.
## Status
Accepted
## Consequences
Client wajib mengirim Idempotency-Key. Layanan pesanan membutuhkan tabel
key dan proses pembersihan. Timeout tidak lagi membuat pesanan ganda.Bagian Consequences paling sering dilewati, padahal di situlah trade-off tercatat. Ketika SLO berubah atau gateway diganti, file ini menunjukkan asumsi mana yang perlu diperiksa ulang.
Untuk sesi belajar berikutnya, pilih satu baris dari tabel di atas, cari keputusan nyata di sistem yang sedang dirawat yang menyentuh area tersebut, lalu tulis ADR-nya. Pertanyaan yang tidak bisa diisi pada bagian Context atau Consequences adalah topik yang perlu dipelajari lebih dulu.