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 bagaimana pekerjaannya terbagi dengan anggota tim lain.
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
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- 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.
- Pendekatan
- 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.
- Yang ditambahkan ke tim
- 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.
Disiplin terkait
Pertanyaan yang sering diajukan
- 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.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya — pekerjaannya, stack-nya, cara tim Anda berjalan — dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.