Backend developer
Backend developer memegang bagian produk yang mengingat. Model data, API, transaksi, pekerjaan latar, otorisasi, dan perilaku sistem ketika sebuah dependency berhenti menjawab semuanya berada di sisi ini. Panduan ini menguraikan cakupan disiplin tersebut, situasi yang membuat backend engineer khusus layak dipertimbangkan, dan cara menilainya tanpa bergantung pada trivia framework.
Apa yang dikerjakan seorang backend developer?
Backend developer membangun dan mengoperasikan sisi server sebuah aplikasi: model data, API yang dipanggil sistem lain, aturan bisnis yang harus berlaku setiap saat, pekerjaan asinkron dan terjadwal yang berjalan di luar request pengguna, serta otorisasi yang menentukan siapa boleh melihat apa. Peran ini bertanggung jawab atas kebenaran data saat diakses bersamaan, atas perilaku sistem ketika sebuah dependency melambat atau tidak tersedia, dan atas tetap terdiagnosisnya sistem setelah ia berjalan di production.
Yang memisahkan pekerjaan backend dari kebanyakan disiplin engineering lain adalah bahwa ia menyimpan state, dan state hidup lebih lama daripada rilis yang menciptakannya. Cacat pada antarmuka selesai dengan mengirim build perbaikan; cacat yang menuliskan baris data yang salah meninggalkan residu yang harus dicari dan diperbaiki lama setelah kodenya dibetulkan. Ketimpangan itulah alasan backend engineer berpengalaman bersikap hati-hati pada titik-titik tertentu — uang, tindakan yang tidak bisa dibatalkan, apa pun yang mengubah sebuah record alih-alih membacanya — dan alasan kehati-hatian itu merupakan kualifikasi, bukan kelambanan.
Kesulitan kedua, sebuah server jarang menangani satu request pada satu waktu. Logika yang jelas benar bila berdiri sendiri menjadi salah ketika dua pemanggil menjalankannya bersamaan, ketika klien mengulang request yang sudah diproses server, atau ketika panggilan jaringan tidak berhasil sekaligus tidak gagal melainkan sekadar berhenti menjawab. Menalar soal interleaving, isolation, locking, idempotensi, dan timeout adalah pekerjaan backend sehari-hari, dan semuanya tak terlihat sampai hari ketika ia tidak ada.
Cakupannya melebar seiring infrastruktur yang tersedia untuknya. Managed queue, object storage, database tereplikasi, dan API pihak ketiga membuat keputusan seorang backend engineer kini ikut menentukan biaya operasional dan seberapa cepat sebuah insiden bisa didiagnosis, bukan hanya fungsi mana yang dijalankan. API juga adalah produk dengan konsumen yang tidak bisa diminta melakukan redeploy sesuka kita, sehingga desain kontrak berubah menjadi komitmen jangka panjang, bukan detail implementasi.
Kapan tim membutuhkan kapabilitas ini
Pekerjaan sisi server kerap dipikul oleh siapa pun yang kebetulan paling dekat, sampai ada sesuatu yang membuat pengaturan itu mahal. Tekanan berikut biasanya yang mengubah backend engineering dari tugas bersama menjadi peran tersendiri.
Model data berubah menjadi faktor pembatas
Setiap fitur baru menuntut satu kolom nullable lagi, satu tabel lookup lagi yang ditempelkan di samping, atau satu query yang menggabungkan lima tabel demi menjawab pertanyaan produk yang sederhana. Skema menumpuk kompromi tanpa bersuara, dan ketika bentuk datanya sudah kelihatan salah, ia sudah menampung record production yang membuat perubahan apa pun menjadi proyek migrasi.
Cacat akibat concurrency mulai bermunculan
Order ganda, saldo yang tidak cocok dengan riwayat transaksinya sendiri, record yang diperbarui oleh dua jalur yang masing-masing merasa dirinya satu-satunya penulis. Cacat semacam ini bergantung pada beban, jarang muncul di mesin developer, dan hampir tidak pernah tuntas diperbaiki oleh orang yang menalarnya satu request pada satu waktu.
API sudah punya konsumen yang tidak Anda kendalikan
Klien mobile yang penggunanya enggan memperbarui aplikasi, integrasi partner, atau service internal milik tim lain. Begitu sebuah kontrak punya konsumen di luar deployment Anda, perubahan menuntut versioning, deprecation, dan pertimbangan kompatibilitas — dan endpoint yang dirancang sebagai kemudahan internal menjadi sangat mahal untuk dikoreksi.
Insiden didiagnosis dengan menebak
Ada yang lambat atau salah, dan satu-satunya bukti yang tersedia adalah dashboard yang memberi tahu bahwa memang ada yang lambat atau salah. Tanpa tracing request, log terstruktur, metrik yang bermakna, dan korelasi antar service, setiap insiden berubah menjadi latihan merilis perubahan yang terdengar masuk akal lalu menunggu apa yang terjadi.
Sebuah alur kerja kini harus terbukti benar
Pembayaran, billing, inventori, payroll, catatan yang diatur regulasi — apa pun yang kalau kira-kira benar berarti salah. Alur seperti ini menuntut batas transaksi, idempotensi, rekonsiliasi, dan jejak audit yang dirancang sejak awal, dan menambahkannya ke alur yang tumbuh apa adanya jauh lebih berat daripada membangunnya secara sadar.
Kapabilitas inti
Desain API
Menetapkan batas resource, semantik error, pagination, filtering, dan versioning agar sebuah kontrak sanggup bertahan menghadapi konsumennya sendiri. Desain API yang baik sebagian besar adalah disiplin memutuskan apa yang tidak diekspos, karena setiap field yang dikembalikan menjadi sesuatu yang bisa saja diandalkan pemanggil.
Pemodelan data
Merepresentasikan sebuah domain sehingga state yang tidak valid sulit dinyatakan — constraint, foreign key, keunikan, dan normalisasi yang sepadan — serta tahu kapan denormalisasi merupakan keputusan performa yang disengaja dan bukan kecelakaan. Termasuk di dalamnya merencanakan perubahan skema pada tabel yang sudah besar dan sudah dipakai.
Transaksi dan isolation
Tahu di mana sebuah transaksi seharusnya dimulai dan diakhiri, apa sebenarnya yang dijamin oleh sebuah isolation level, dan anomali mana yang tetap mungkin terjadi di bawahnya. Rangkaian read-modify-write yang dijalankan di luar transaksi termasuk sumber korupsi data paling sering pada sistem production, dan ia terjadi tanpa suara.
Concurrency dan idempotensi
Merancang operasi yang tetap benar ketika dijalankan dua kali, dijalankan bersamaan, atau terhenti di tengah jalan. Idempotency key, optimistic locking, unique constraint sebagai benteng terakhir, dan sikap yang eksplisit tentang operasi mana yang aman untuk diulang.
Penanganan kegagalan
Timeout pada setiap panggilan keluar, retry dengan backoff dan jitter hanya di tempat yang memang aman diulang, circuit breaking, degradasi yang terkendali, dan backpressure. Pertimbangan yang penting adalah memutuskan apa yang harus dilakukan sistem ketika sebuah dependency tidak tersedia, alih-alih menemukan jawabannya di tengah insiden.
Pekerjaan asinkron dan terjadwal
Memindahkan pekerjaan keluar dari jalur request lewat queue, worker, dan job terjadwal, lalu menghadapi apa yang dibawanya: urutan, pengiriman ganda, poison message, penanganan dead letter, dan pertanyaan operasional tentang apa yang terjadi pada antrean yang menumpuk semalaman.
Caching
Memutuskan apa yang boleh di-cache, untuk berapa lama, dan bagaimana ia diinvalidasi — sambil jujur bahwa strategi invalidasi itulah seluruh persoalannya. Termasuk mengenali kapan sebuah cache sebenarnya sedang menutupi query yang semestinya diperbaiki.
Observability
Log terstruktur dengan identifier korelasi, metrik yang menggambarkan perilaku yang dialami pengguna dan bukan sekadar kesehatan mesin, distributed tracing, serta alert yang terikat pada gejala yang benar-benar dipedulikan orang. Ujinya sederhana: bisakah engineer yang belum mengenal sistem itu mendiagnosis kegagalan baru hanya dari apa yang sudah dipancarkan sistem tersebut.
Keamanan dan otorisasi
Autentikasi dan penanganan session, model otorisasi yang ditegakkan di titik akses data alih-alih di antarmuka, query yang terparameterisasi, pengelolaan secret, dan kehati-hatian menangani data pribadi. Kebocoran sisi server yang paling merugikan umumnya berupa celah otorisasi biasa, bukan eksploitasi yang eksotis.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam backend engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun — dalam pekerjaan backend, pengetahuan yang benar-benar berpindah ada pada pemodelan data, concurrency, dan perilaku saat gagal, yang jauh lebih mudah dibawa antar runtime dibanding sintaks framework.
Bahasa dan runtime
- Java
- Go
- Python
- Node.js
- C#
- Kotlin
- Ruby
- PHP
- Rust
Framework server
- Spring Boot
- Django
- FastAPI
- NestJS
- Express
- Laravel
- Rails
- ASP.NET Core
Penyimpanan data
- PostgreSQL
- MySQL
- MongoDB
- Redis
- Elasticsearch
- ClickHouse
- DynamoDB
API dan integrasi
- REST
- GraphQL
- gRPC
- OpenAPI
- WebSockets
- Webhooks
Messaging dan pekerjaan latar
- Kafka
- RabbitMQ
- Amazon SQS
- NATS
- Celery
- Temporal
- Sidekiq
Observability
- OpenTelemetry
- Prometheus
- Grafana
- Jaeger
- Sentry
- Datadog
Testing dan delivery
- Testcontainers
- pytest
- JUnit
- k6
- Docker
- GitHub Actions
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Apa yang perlu dinilai saat memilih kandidat
Kandidat backend sulit dinilai dari artefak. Tidak ada portofolio untuk dilihat, kodenya jarang terbuka, dan kualitas yang paling menentukan — kehati-hatian terhadap state, cara berpikir yang jernih soal kegagalan — baru muncul dalam percakapan tentang keputusan konkret di masa lalu. Area berikut layak digali.
Pertimbangan dalam pemodelan data
Minta mereka menjelaskan sebuah skema yang mereka rancang dan apa yang ingin mereka ubah sekarang. Engineer yang hidup bersama modelnya sendiri selama beberapa tahun membicarakannya dengan cara yang sangat berbeda dari engineer yang menyerahkan rancangannya lalu pindah.
- Memakai constraint database untuk menegakkan invarian, bukan hanya mengandalkan kode aplikasi
- Bisa menjelaskan satu denormalisasi yang ia lakukan dan ongkos yang ia terima karenanya
- Pernah memigrasikan tabel besar di production dan bisa menjelaskan cara ia menghindari downtime
- Memperlakukan penghapusan atau penggantian nama kolom sebagai proses bertahap, bukan satu perubahan
Kebenaran di bawah concurrency
Ini pembeda paling andal antara backend engineer level menengah dan senior. Ajukan skenario read-modify-write yang biasa saja, lalu lihat apakah mereka menyadari sendiri adanya race tanpa perlu diarahkan.
- Menjangkau transaksi, lock, atau unique constraint tepat pada titik yang benar
- Bisa menjelaskan apa yang dicegah dan tidak dicegah oleh sebuah isolation level tertentu
- Merancang operasi tulis agar aman diulang
- Membedakan race yang menghilangkan sebuah update dari race yang sekadar mengubah urutan pekerjaan
Cara berpikir tentang kontrak API
Tanyakan bagaimana mereka akan menambahkan field wajib ke endpoint yang sudah dipanggil klien yang ada. Jawabannya memperlihatkan apakah mereka memandang API sebagai kode milik sendiri atau sebagai janji yang telah dibuat kepada orang lain.
- Merencanakan perubahan aditif sebelum breaking change, dan versioning sebelum keduanya
- Punya pendapat soal respons error yang lebih matang daripada sekadar status code
- Memikirkan pagination dan batas hasil sebelum datanya membesar
- Mendokumentasikan kontraknya di tempat yang benar-benar bisa dipakai konsumen
Perilaku ketika dependency gagal
Setiap sistem backend yang serius memanggil sesuatu yang tidak ia kendalikan. Tanyakan apa yang dilakukan service mereka ketika panggilan itu memakan waktu jauh lebih lama dari biasanya — jawaban yang kuat spesifik soal timeout, fallback, dan apa yang akhirnya dilihat pemanggil.
- Menetapkan timeout secara eksplisit alih-alih mewarisi default library
- Hanya mengulang operasi yang aman diulang, dan dengan backoff
- Bisa menggambarkan mode degradasi yang membuat produk tetap bisa dipakai
- Memikirkan efek kegagalan itu terhadap queue, pool, dan pemanggil di hulu
Diagnosis di production
Minta mereka menuturkan satu insiden nyata: sinyal pertama yang mereka lihat, kemungkinan yang mereka singkirkan, dan bukti yang akhirnya menuntaskannya. Dengarkan apakah kesimpulan ditarik dari apa yang dilaporkan sistem, atau dari intuisi yang dibentuk sejak awal lalu dibela.
- Bekerja dari trace, log terstruktur, dan metrik, bukan dari firasat
- Memisahkan pemicu sebuah insiden dari penyebab yang mendasarinya
- Pernah menambahkan instrumentasi sebagai jawaban atas sesuatu yang tidak bisa ia lihat
- Bisa menceritakan mitigasi yang diterapkan sebelum diagnosis lengkap tersedia
Naluri keamanan
Anda tidak sedang mencari spesialis keamanan. Anda mencari orang yang kebiasaan bawaannya adalah menegakkan akses di lapisan data dan menaruh curiga pada input, karena kebiasaan itulah yang mencegah sebagian besar eksposur biasa di sisi server.
- Menegakkan otorisasi di setiap jalur menuju sebuah record, bukan hanya jalur yang paling kelihatan
- Memperlakukan identifier yang datang dari klien sebagai tidak tepercaya, apa pun sumbernya
- Paham mengapa query terparameterisasi penting dan tidak menganggap ORM meniadakan persoalannya
- Berhati-hati soal apa yang muncul di log dan di respons error
Pendekatan testing
Tanyakan apa yang mereka uji terhadap database sungguhan dan apa yang mereka ganti dengan pengganti. Suite backend yang menirukan lapisan data cenderung lolos sementara query, constraint, dan transaksi yang sebenarnya tetap tidak terverifikasi.
- Menguji perilaku database yang sesungguhnya di suatu bagian suite
- Menguji batasnya — hasil kosong, duplikat, penulisan bersamaan
- Bisa menyebut satu bug yang lolos dari test mereka dan apa yang mereka ubah setelahnya
Pertanyaan wawancara yang layak diajukan
Pertanyaan berikut disusun untuk memunculkan penalaran soal state dan kegagalan, bukan hafalan sintaks. Semuanya disediakan untuk dipakai dalam proses wawancara Anda sendiri, yang tetap sepenuhnya Anda jalankan — setiap kandidat dinilai tim Anda sebelum bergabung ke dalamnya.
Seorang klien mengirim permintaan pembayaran, responsnya hilang, lalu klien mengulang permintaan itu. Apa yang Anda bangun agar pelanggan tidak tertagih dua kali?
What a strong answer shows
Apakah idempotensi adalah kebiasaan atau sekadar istilah. Jawaban yang kuat menjelaskan key yang dikirim klien, constraint keunikan yang bertahan menghadapi percobaan bersamaan, dan hasil tersimpan yang dikembalikan ke pemanggil ulang — bukan pengecekan sebelum insert yang diharapkan atomik.
Anda harus menambahkan kolom non-null ke tabel besar yang terus-menerus ditulisi. Bagaimana Anda melakukannya?
What a strong answer shows
Pengalaman migrasi yang nyata. Cari pendekatan bertahap — tambahkan sebagai nullable, backfill per batch, tulis ke keduanya, lalu tegakkan — dan kesadaran soal perilaku locking, lag replikasi, serta urutan deploy yang menjaga kode lama tetap bekerja sepanjang prosesnya.
Sebuah endpoint cepat secara rata-rata, tetapi lambat sampai tak bisa diterima untuk sebagian kecil request. Anda memeriksa dari mana?
What a strong answer shows
Apakah mereka berpikir dalam distribusi. Jawaban yang kuat menolak angka rata-rata sebagai bukti, mencari jalur yang biayanya berubah-ubah — index yang hilang, hasil yang tak dibatasi, cache yang dingin, rebutan pada pool — dan memakai tracing untuk menemukan ke mana waktunya sebenarnya pergi.
Kapan Anda memindahkan pekerjaan ke queue, dan masalah apa yang ditimbulkannya?
What a strong answer shows
Pertimbangan yang berimbang. Siapa pun bisa menyebutkan manfaatnya. Jawaban yang berguna menyebut ongkosnya: eventual consistency yang kini harus diungkapkan produk, pengiriman ganda, urutan yang tidak lagi dijamin, job gagal yang butuh tempat berlabuh, dan antrean yang kini menjadi urusan operasional.
Bagaimana Anda memastikan seorang pengguna tidak bisa membaca data pengguna lain lewat API Anda?
What a strong answer shows
Di mana mereka meletakkan kontrolnya. Jawaban yang kuat menegakkan kepemilikan di dalam query atau di lapisan akses data sehingga berlaku pada setiap route, alih-alih pada pengecekan per endpoint yang bisa terlewat diam-diam oleh handler baru. Dengarkan juga bagaimana mereka akan mengujinya.
Ceritakan saat service Anda menyajikan data basi atau salah karena sebuah cache. Bagaimana itu bisa terjadi?
What a strong answer shows
Riwayat operasional yang nyata. Jawaban yang baik spesifik tentang jalur invalidasi yang terlewat, dan reflektif soal apakah cache itu sedang menyelesaikan masalah yang semestinya diselesaikan oleh perubahan skema atau index.
Anda dipanggil karena lonjakan error dan sudah punya log, metrik, dan trace, tetapi belum ada penyebab yang jelas. Ceritakan lima belas menit pertama Anda.
What a strong answer shows
Metode menangani insiden di bawah tekanan. Cari urutan menstabilkan lebih dulu sebelum mendiagnosis, mengorelasikan dengan deploy terakhir dan kesehatan dependency, mempersempit lewat perbandingan, serta mengomunikasikan status — bukan langsung membaca kode.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Sebuah tim engineering memikul permukaan API yang terus bertambah berikut model data yang telah menyerap perubahan produk selama beberapa tahun. Performa query menurun pada alur-alur tertentu, background job perlu dirombak, dan tim tidak bisa menyentuh satu pun di antaranya tanpa menghentikan pengiriman roadmap yang sudah dijanjikan.
- Approach
- Kapasitas backend tambahan masuk ke dalam cara kerja tim yang sudah mapan — batas kepemilikan service mereka, standar review mereka, proses deployment mereka, dan arah arsitektur yang sudah mereka tetapkan. Prioritas tetap ditentukan di internal, dan kapasitas tambahan mengambil pekerjaan dari backlog yang sama alih-alih menjalankan jalur terpisah.
- What this adds to the team
- Tim mendapat ruang untuk menggarap pekerjaan struktural sambil tetap merilis. Keputusan soal model data, kontrak API, dan arah sistem tetap berada pada engineer yang bertanggung jawab atas produknya.
Related disciplines
Frequently asked questions
- Apa beda backend developer dan platform engineer?
- Backend developer membangun logika aplikasi dan model data yang menjadi tumpuan produk. Platform engineer membangun infrastruktur dan tooling internal tempat tim aplikasi melakukan deployment — cluster, pipeline, environment, dan perkakas observability. Keduanya beririsan pada containerisasi dan layanan cloud, dan backend engineer yang kuat biasanya nyaman mengoperasikan apa yang ia bangun, tetapi keduanya bukan pengganti satu sama lain: menyerahkan tanggung jawab platform sepenuhnya kepada seorang backend developer cenderung menghasilkan infrastruktur yang pas untuk satu service dan tidak untuk yang lain.
- Apakah backend developer perlu keahlian database yang mendalam?
- Cukup untuk merancang skema yang sehat, membaca execution plan, membuat index secara sadar, dan memahami perilaku transaksional. Itu standar yang berarti, dan banyak kandidat belum melewatinya. Topologi replikasi, tuning storage engine, strategi sharding, dan perencanaan pemulihan yang rumit adalah tempat spesialis database benar-benar bernilai, dan tim yang menjalankan cluster dengan beban berat umumnya membutuhkan keduanya, bukan satu orang yang ditarik ke dua arah.
- Seberapa penting bahasa pemrograman saat memilih kandidat?
- Tidak sepenting ekosistem di sekelilingnya. Concurrency, pemodelan data, dan perilaku saat gagal adalah pengetahuan yang bertahan lama, dan ketiganya berpindah antar runtime sejenis tanpa banyak hambatan. Yang berpindah lambat adalah kefasihan pada konvensi dan perkakas operasional sebuah ekosistem tertentu — jadi beri bobot lebih pada pengalaman bahasa ketika keterlibatannya singkat atau runtime-nya tidak lazim, dan bobot lebih kecil ketika ada waktu untuk menyesuaikan diri di stack arus utama.
- Apakah backend developer sebaiknya ikut on call untuk apa yang ia bangun?
- Bila model operasi tim mendukungnya, ya — engineer yang menanggung konsekuensi keputusan desainnya cenderung mengambil keputusan yang lebih baik. Yang penting adalah hal itu menjadi norma tim yang diterapkan konsisten, disertai observability dan runbook yang membuat on call masuk akal dijalani, bukan ekspektasi yang ditempelkan ke orang per orang setelah keadaan terjadi.
- Kapan backend developer khusus lebih tepat daripada full-stack developer?
- Ketika kesulitan produknya berada di balik antarmuka. Volume tulis yang tinggi, aturan domain yang berbelit, banyak integrasi, alur kerja yang diatur regulasi, dan target keandalan yang ketat semuanya memberi imbalan pada kedalaman di pemodelan data dan perilaku sistem terdistribusi. Ketika sisi server sebagian besar hanya baca dan tulis yang lurus dan antarmukalah yang memikul produk, keluasan full-stack biasanya memberi hasil lebih banyak per orang.
- Tingkat senioritas seperti apa yang dituntut pekerjaan backend?
- Bergantung pada seberapa banyak yang sudah diputuskan. Mengimplementasikan endpoint di dalam skema, struktur service, dan pendekatan testing yang sudah mapan sangat cocok untuk engineer level menengah. Menetapkan model data, mendefinisikan batas service, atau memimpin dekomposisi menuntut orang yang pernah hidup bersama konsekuensi pilihan-pilihan itu, karena ongkos salah memilih dibayar perlahan dan jarang bisa dibalik.
- Bagaimana backend developer bekerja bersama tim engineering yang sudah ada?
- Sehari-hari hubungan kerjanya adalah dengan tim Anda: arsitektur Anda, code review Anda, model kepemilikan service Anda, dan prioritas sprint Anda. Arah teknis tetap di tangan Anda. Dalam model penambahan kapasitas tim engineering, yang berada di sisi Talent.ID adalah hubungan kerja — payroll, benefit karyawan, administrasi talenta, dan hubungan karyawan yang berkelanjutan.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.