Wawancara Backend: Bagaimana Cara Anda Mendesain API untuk Operasi Berdurasi Panjang (Long-Running Operations)?

Konteks dan Cakupan Masalah

Sebuah platform analitik B2B membutuhkan API ekspor laporan. Satu kali ekspor memakan waktu 5 menit hingga 3 jam dan dapat menghasilkan file sebesar 20 GiB. Layanan ini dapat menerima 10.000 pengiriman sekitar pukul 09:00 setiap hari. Pemanggil mencakup browser dan layanan yang dioperasikan oleh perusahaan lain. API gateway menutup permintaan sinkron setelah 30 detik, sehingga pemanggil dapat mencoba lagi jika tidak menerima respons.

Pengguna harus dapat melihat apakah pekerjaan sedang dalam antrean (queued), berjalan (running), berhasil (successful), atau gagal (failed). Mereka juga harus dapat meminta pembatalan selagi memungkinkan dan mengunduh hasil yang sukses. Durasi, ukuran file, jam sibuk, dan batas waktu merupakan asumsi kasus wawancara, bukan tolok ukur industri. Partisi antrean berada di luar fokus utama pertanyaan ini. Tugas utamanya adalah menentukan kontrak HTTP asinkron yang tetap dapat dipahami meskipun terjadi percobaan ulang (retries), proses crash, dan race condition pada status.

RFC 9110 menyatakan bahwa 202 Accepted berarti permintaan telah diterima untuk diproses tetapi pemrosesan belum selesai dan mungkin tidak akan pernah terjadi. Respons harus menjelaskan status terkini dan mengarahkan ke pemantau status. Panduan wawancara REST API tingkat senior saat ini juga meminta kandidat untuk merancang operasi berdurasi panjang, termasuk status, kegagalan, pembatalan, dan idempotensi. Pertanyaan ini cocok untuk backend engineer, API platform engineer, dan senior full-stack engineer yang mendesain kontrak layanan, sehingga kategori intinya adalah backend.

Hal yang Dievaluasi oleh Pewawancara

Pertama, apakah kandidat memahami batasan dari 202? Ini tidak berarti "pekerjaan latar belakang pasti berhasil," dan pekerjaan yang belum selesai bukanlah hasil akhir 200 OK. Jawaban yang kuat akan menolak permintaan tidak valid yang langsung terdeteksi secara sinkron, kemudian mengembalikan operation resource yang stabil setelah penerimaan yang persisten dan menampilkan hasil eksekusi sebagai status di kemudian hari.

Kedua, bisakah kandidat memodelkan pekerjaan berdurasi panjang sebagai sebuah resource, bukan hanya mengembalikan ID pesan antrean? Sebuah operasi memerlukan pemilik tenant, sidik jari permintaan (request fingerprint), status, progres, hasil atau error, versi, waktu pembuatan, dan waktu kedaluwarsa. State machine-nya harus mendefinisikan transisi yang diizinkan, status akhir (terminal states), dan race condition pembatalan.

Ketiga, apakah ada celah di mana server telah mengembalikan 202 tetapi pekerjaannya tidak pernah masuk ke antrean? Catatan operasi dan data pekerjaan yang akan dipublikasikan harus disimpan dalam satu transaksi database, kemudian outbox publisher dapat memasukkannya ke dalam antrean. Konsumen dan tahap eksekusi tetap membutuhkan idempotensi karena pengiriman at-least-once, worker crash, dan pengambilalihan lease dapat menduplikasi pekerjaan.

Keempat, bisakah kontrak klien bertahan di bawah beban lalu lintas nyata? Location memberi tahu klien di mana harus memeriksa status. Retry-After, backoff, jitter, dan conditional requests mengendalikan polling. Webhook bertanda tangan dapat memberi tahu pemanggil server-to-server, dan SSE dapat memperbarui browser, tetapi keduanya tidak menggantikan operation resource yang dapat di-query untuk kebutuhan pemulihan.

Terakhir, pewawancara ingin mendengar skenario keamanan dan verifikasi. ID acak yang tidak dapat ditebak bukanlah otorisasi tingkat objek (object-level authorization), dan URL hasil tidak boleh melewati batas-batas tenant. Jawaban yang kuat akan menguji respons penerimaan yang hilang, pengiriman duplikat, kegagalan publikasi, worker crash, race condition antara pembatalan dan penyelesaian, lonjakan polling, serta pembersihan data kedaluwarsa.

Pertanyaan yang Perlu Diklarifikasi Terlebih Dahulu

• Apa yang harus divalidasi secara sinkron? Identitas, izin tenant, format permintaan, keberadaan input, dan pelanggaran kuota yang jelas harus diperiksa sebelum penerimaan. Jika kelengkapan data hanya dapat diketahui setelah pemindaian selama beberapa jam, itu adalah kegagalan eksekusi asinkron, bukan janji yang dibuat saat penerimaan.
• Apakah permintaan duplikat berarti percobaan ulang (retry) atau operasi independen kedua? Ketika pemanggil menyertakan Idempotency-Key, tenant, endpoint, key, dan sidik jari permintaan yang sama harus memutar ulang satu operasi yang sama. Pemanggil yang secara sengaja membutuhkan dua ekspor identik harus menggunakan dua key berbeda.
• Apakah progres dapat diukur? Jika jumlah total partisi diketahui, laporkan unit yang selesai dan total unit. Jika tidak dapat diperkirakan, laporkan fase dan heartbeat terakhir daripada mengarang persentase yang tertahan di 99%.
• Resource seperti apa hasilnya? Hasil kecil dapat disematkan dalam respons operasi. File besar harus menjadi resource terpisah yang dilindungi. Kasus ini menggunakan kredensial unduhan berumur pendek serta periode retensi terpisah untuk metadata operasi, objek hasil, dan kredensial unduhan.
• Apa jaminan dari pembatalan? Apakah itu hanya menghentikan pekerjaan di masa mendatang, atau harus membatalkan efek samping yang sudah terlanjur diterapkan? Jika langkah-langkahnya tidak dapat dibatalkan, kontrak harus mendefinisikan pembatalan best-effort, kompensasi, output parsial, dan kemungkinan status akhir.
• Saluran notifikasi apa yang dapat diterima pemanggil? Browser biasanya tidak dapat menyediakan endpoint callback, sehingga polling atau SSE lebih cocok. Pemanggil server-to-server dapat menggunakan webhook. Kendala jaringan dan target latensi mengubah saluran notifikasi, tetapi operation resource tetap menjadi sumber kebenaran (source of truth).
• Bisakah operasi paralel mengalami konflik? Bisakah satu konfigurasi laporan diekspor secara bersamaan? Apa yang terjadi jika konfigurasi tersebut diperbarui atau dihapus selama eksekusi? Jawabannya menentukan apakah perlu melakukan serialisasi, membuat snapshot input, menolak konflik, atau membiarkan versi lama selesai.
• Berapa lama status disimpan? Kasus ini mempertahankan operasi terminal selama 7 hari, objek hasil selama 24 jam, dan setiap kredensial unduhan selama 15 menit. Ini adalah pilihan kontrak produk yang harus disesuaikan dengan kebutuhan audit, biaya, dan kemampuan untuk membuat ulang hasil.

Kerangka Jawaban 30 Detik

"Saya akan memisahkan eksekusi dari permintaan HTTP, tetapi saya tidak akan hanya mengembalikan job ID. Endpoint pengiriman memvalidasi otorisasi dan error yang dapat langsung dideteksi, lalu menulis operasi dan catatan outbox dalam satu transaksi database. Setelah berhasil di-commit, endpoint mengembalikan 202, Location, dan interval polling yang disarankan. Operation resource yang terotorisasi menyediakan status yang stabil, progres nyata, error terstruktur, dan tautan hasil. Idempotency key dan permintaan yang sama akan memutar ulang operasi yang sama. Worker memproses berdasarkan ID operasi secara idempoten, sementara kondisi versi melindungi transisi status. Polling menggunakan Retry-After, backoff, dan jitter; pemanggil server dapat menambahkan webhook bertanda tangan; pembatalan masuk ke status cancel_requested dan menyelesaikan race condition dengan penyelesaian. Saya kemudian akan menguji skenario kehilangan respons, pesan duplikat, worker crash, race condition pembatalan, dan masa kedaluwarsa untuk memastikan tidak ada ghost job, hasil duplikat yang terlihat, atau unduhan tanpa izin."

Pembahasan Mendalam Langkah demi Langkah

Pertama, definisikan dua resource. Permintaan ekspor menyatakan hasil yang ingin dibuat pengguna, sedangkan operation resource mewakili siklus hidup eksekusi ini. Pengiriman dapat berupa POST /v1/report-exports, dan statusnya dapat berupa GET /v1/report-operations/{operation_id}. Respons penerimaan dapat berupa:

HTTP/1.1 202 Accepted
Location: /v1/report-operations/op_7f3a
Retry-After: 5
Content-Type: application/json

{
  "id": "op_7f3a",
  "status": "queued",
  "statusUrl": "/v1/report-operations/op_7f3a",
  "cancelUrl": "/v1/report-operations/op_7f3a"
}

202 hanya menjanjikan bahwa pemrosesan telah diterima. Tolak permintaan yang salah format (malformed), pemanggil yang tidak terotorisasi, atau input yang tidak ada dengan 4xx yang sesuai dan jangan membuat operasi. Simpan kegagalan bisnis yang memerlukan komputasi mahal di dalam operation resource. Location dan Retry-After adalah bagian dari kontrak klien API ini; RFC 9110 tidak mewajibkan setiap respons 202 menggunakan kedua header tersebut.

Kedua, definisikan catatan operasi dan state machine. Catatan minimal berisi id, tenant_id, idempotency_key, request_fingerprint, status, progres, referensi hasil, error terstruktur, version, stempel waktu pembuatan dan pembaruan, serta expires_at. Rangkaian transisi yang disarankan adalah:

queued -> running -> succeeded
                 -> failed
queued  -> cancel_requested -> canceled
running -> cancel_requested -> canceled | succeeded | failed

Pembatalan dan penyelesaian dapat saling berkejaran (race condition), sehingga cancel_requested bukanlah status terminal. Worker melakukan commit hasil dengan pembaruan bersyarat pada version dan status sebelumnya yang diizinkan; hanya satu transisi yang menang. Jika efek samping sudah tidak dapat diubah, pembatalan pada akhirnya dapat menjadi succeeded atau failed. Jangan mengarang status canceled hanya untuk mencocokkan label tombol di antarmuka pengguna. Representasi status dapat terlihat seperti ini:

{
  "id": "op_7f3a",
  "status": "running",
  "progress": {
    "completedUnits": 37,
    "totalUnits": 100
  },
  "result": null,
  "error": null,
  "lastUpdatedAt": "2026-07-18T23:18:11Z",
  "expiresAt": "2026-07-25T23:08:11Z"
}

Kembalikan progres ini hanya jika unit kerja memiliki penyebut (denominator) yang nyata. Eksekusi yang gagal masih dapat mengembalikan 200 jika pembacaan operasi itu sendiri berhasil, dengan kegagalan yang dinyatakan oleh status terminal dan error terstruktur: pembacaan status berhasil sementara eksekusi yang diwakilinya gagal. Tim yang memilih untuk memetakan kegagalan eksekusi ke kode 4xx dari endpoint status harus menggunakan konvensi tersebut secara konsisten di setiap SDK daripada mencampuradukkan kedua makna tersebut.

Ketiga, pastikan penerimaan, percobaan ulang, dan eksekusi berjalan dengan benar. Berikan unique constraint pada (tenant_id, route, idempotency_key) dan simpan sidik jari dari canonical request. Key dan sidik jari yang sama akan mengembalikan operasi yang ada dan status saat ini. Key yang sama dengan sidik jari berbeda akan mengembalikan conflict secara eksplisit, mencegah penggunaan ulang key yang tidak disengaja untuk laporan lain. Pertahankan catatan idempotensi setidaknya selama klien secara sah dapat mencoba kembali dan koordinasikan dengan retensi operasi.

Masukkan operasi dan event outbox dalam satu transaksi database, lalu kembalikan 202. Publisher terpisah mengirimkan event outbox ke antrean dan mungkin mengirimkannya lebih dari sekali. Konsumen melakukan deduplikasi berdasarkan ID operasi. Setiap tahap eksekusi juga memerlukan penulisan idempoten atau fencing token sehingga worker crash setelah penulisan eksternal, yang diikuti oleh pengambilalihan proses, tidak menghasilkan dua output yang terlihat. Jawaban API perlu membuktikan batas penerimaan ke antrean; tidak perlu membuat ulang desain scheduler secara lengkap.

Keempat, kendalikan lalu lintas status dan notifikasi. Respons status awal dan lanjutan menyediakan Retry-After yang wajar. Klien menggunakan exponential backoff dengan batas atas (cap) dan jitter, sementara server mendukung ETag dan conditional requests untuk menghindari pengiriman ulang body yang tidak berubah. Jika pembacaan status melebihi kuota, kembalikan informasi pembatasan laju permintaan (rate-limit) daripada membiarkan 10.000 pemanggil melakukan polling setiap detik.

Browser yang membutuhkan progres latensi rendah dapat berlangganan ke SSE dan tetap dapat melakukan query berdasarkan ID operasi setelah terputus. Pemanggil server dapat mendaftarkan webhook bertanda tangan; pengirim mencoba kembali jika gagal, dan penerima melakukan deduplikasi. Kedua saluran push dapat hilang, tertunda, atau terduplikasi, sehingga operation resource tetap menjadi sumber kebenaran untuk pemulihan dan rekonsiliasi. Jika berhasil, body operasi dapat menautkan ke hasilnya. Jika API justru mengarahkan ke resource hasil yang berbeda, dokumentasikan semantik 303 dan pastikan SDK tidak memutar ulang POST awal di lokasi hasil.

Kelima, tangani otorisasi, pembatalan, dan retensi. Setiap pembacaan status, pembatalan, dan pengambilan hasil melakukan otorisasi tingkat objek terhadap tenant_id, identitas pemanggil, dan izin operasi. ID acak mempersulit enumerasi tetapi bukan merupakan bentuk otorisasi. Layanan unduhan memverifikasi kembali kepemilikan hasil, lalu menerbitkan kredensial 15 menit yang dipilih untuk kasus ini. Respons operasi tidak pernah menyimpan URL publik yang berumur panjang.

DELETE /v1/report-operations/{id} dapat digunakan untuk menyatakan permintaan pembatalan. Jika pembatalan memungkinkan, kembalikan representasi cancel_requested saat ini untuk menunjukkan bahwa permintaan telah diterima. Jika tidak memungkinkan atau operasi sudah dalam status terminal, kembalikan respons stabil yang aman untuk dicoba kembali. Worker memeriksa penanda pembatalan pada batas antartahap, melewati langkah-langkah berikutnya, dan menghapus objek sementara. Efek samping eksternal yang sudah terlanjur di-commit mengikuti aturan kompensasi yang telah ditentukan sebelumnya. Hapus operasi terminal setelah 7 hari. ID kedaluwarsa yang diketahui dapat mengembalikan 410 Gone, sedangkan ID yang tidak dikenal atau tidak terotorisasi dapat mengembalikan 404 sesuai dengan kebijakan pengungkapan (disclosure policy).

Keenam, verifikasi kegagalan alih-alih hanya menguji skenario sukses (happy path). Cakup setidaknya kasus-kasus berikut: server melakukan commit tetapi kehilangan respons 202, dan percobaan ulang hanya dapat mengambil operasi yang sama; outbox publisher mengalami crash sebelum atau sesudah pengiriman, dan pekerjaan akhirnya tetap ada dengan satu hasil yang terlihat; worker kehilangan acknowledgement setelah menulis hasil, dan penerusnya tidak dapat menimpa status terminal; pembatalan dan penyelesaian tiba bersamaan, dan hanya satu status terminal yang sah yang muncul; polling status yang tidak berubah mengikuti backoff dan conditional requests; akses status, pembatalan, dan pengunduhan lintas-tenant semuanya gagal; metadata, hasil, dan idempotency key kedaluwarsa sesuai dengan kontrak.

Aturan keputusan yang dapat digunakan kembali adalah: 202 menyelesaikan masalah antrean koneksi, operation resource menyelesaikan visibilitas (observability), dan penerimaan atomik ditambah state machine yang idempoten menyelesaikan kebenaran sistem.

Contoh Jawaban Berkualitas Tinggi

"Pertama-tama saya akan memisahkan keberhasilan penerimaan dari keberhasilan eksekusi. Operasi ini dapat memakan waktu hingga 3 jam dan tidak boleh menahan koneksi gateway yang batas waktunya 30 detik. Oleh karena itu, POST /v1/report-exports memeriksa identitas, izin tenant, format permintaan, keberadaan input, dan pelanggaran kuota yang jelas. Kemudian ia membuat operasi dan catatan outbox dalam satu transaksi database dan hanya mengembalikan 202 setelah commit berhasil. Respons mencakup Location untuk operation resource dan Retry-After untuk pembacaan status pertama. Status 202 tidak menjamin bahwa pembuatan laporan akan berhasil.

Operasi menyimpan kepemilikan tenant, idempotency key, sidik jari permintaan, status, progres yang dapat diverifikasi, hasil atau error, versi, dan masa kedaluwarsa. Status bergerak dari queued ke running, lalu ke succeeded atau failed. Pembatalan pertama-tama masuk ke cancel_requested karena worker mungkin sedang melakukan commit hasil pada saat yang sama. Di bawah tenant dan endpoint yang sama, idempotency key dan permintaan yang sama mengembalikan satu operasi; key yang sama dengan permintaan berbeda menghasilkan conflict. Dengan demikian, respons 202 yang hilang tidak akan membuat laporan kedua saat klien mencoba lagi.

Saya mengasumsikan pengiriman antrean at-least-once. Outbox dapat mempublikasikan dua kali, konsumen melakukan deduplikasi berdasarkan ID operasi, dan penulisan eksternal di setiap tahap bersifat idempoten atau menggunakan fencing token. Pembaruan status menyertakan kondisi versi sehingga worker yang stale tidak dapat menimpa hasil setelah lease-nya diambil alih. Kegagalan sebelum penerimaan langsung mengembalikan kode 4xx. Kegagalan selama eksekusi disimpan sebagai status terminal dan error terstruktur, yang memungkinkan klien membedakan kegagalan jaringan, kegagalan pembacaan status, dan kegagalan eksekusi laporan.

Klien melakukan polling sesuai dengan Retry-After dengan exponential backoff dan jitter, dan endpoint status mendukung ETag. Browser dapat menggunakan SSE untuk melihat progres langsung dan layanan mitra dapat menggunakan webhook bertanda tangan, tetapi keduanya tetap memulihkan kondisi melalui operation resource setelah terputus atau saat menerima notifikasi duplikat. File hasil tidak pernah memiliki URL publik. Endpoint unduhan melakukan otorisasi ulang dan menerbitkan kredensial 15 menit. Dalam kasus ini, operasi terminal bertahan selama 7 hari dan file selama 24 jam, dan aturan kedaluwarsa tersebut merupakan bagian dari kontrak publik.

Terakhir, saya akan menguji respons yang hilang setelah commit, pengiriman outbox berulang, worker crash setelah menulis hasil, race condition antara pembatalan dan penyelesaian, 10.000 pemanggil yang melakukan polling secara bersamaan, dan akses lintas-tenant. Lulus pengujian berarti lebih dari sekadar berhasil selesai sekali di latar belakang: kegagalan-kegagalan ini tidak boleh menghasilkan ghost job, hasil duplikat yang terlihat, transisi ilegal, atau unduhan tanpa izin."

Kesalahan Umum

• Memulai in-memory thread setelah mengembalikan 202 → restart proses akan meninggalkan pekerjaan yang tidak akan pernah bisa ditemukan, dan penerimaan tidak bersifat atomik dengan peluncuran tugas → simpan operasi dan outbox secara persisten sebelum mengonfirmasi penerimaan.
• Menganggap 202 sebagai keberhasilan akhir → HTTP secara eksplisit mengizinkan pemrosesan untuk gagal atau tidak pernah terjadi → tampilkan hasil akhir, error, dan pemantau status dalam kontrak lanjutan.
• Hanya mengembalikan ID pesan antrean → tidak memiliki informasi kepemilikan tenant, status yang stabil, error, hasil, dan retensi → buat operation resource terpisah yang terotorisasi.
• Melakukan polling satu detik sekali terus-menerus → lonjakan pengiriman berubah menjadi lonjakan pembacaan yang berkelanjutan → sediakan Retry-After dan gunakan backoff, jitter, ETag, serta kuota.
• Menggunakan ID operasi acak sebagai bentuk otorisasi → log yang bocor, riwayat browser, atau tautan internal masih dapat memberikan akses lintas-tenant → otorisasi setiap pembacaan status, pembatalan, dan pengambilan hasil.
• Hanya menyimpan idempotency key dalam Redis lock jangka pendek → kedaluwarsa lock, crash, dan replay hasil masih dapat menciptakan operasi duplikat → gunakan unique constraint yang persisten, sidik jari permintaan, dan respons yang dapat diputar ulang.
• Menandai operasi sebagai canceled segera setelah pengguna mengklik → worker mungkin sudah terlanjur melakukan commit efek yang tidak dapat diubah → masuk ke cancel_requested terlebih dahulu dan biarkan transisi bersyarat serta kompensasi menentukan status terminal yang sah.
• Selalu mengarang nilai persentase → tahapan yang tidak dapat diprediksi akan tertahan di 99% dan menyesatkan pemanggil → laporkan unit yang selesai jika dapat diukur, jika tidak, laporkan fase dan waktu pembaruan.
• Menghapus operasi setelah webhook berhasil dikirim → notifikasi dapat hilang, terduplikasi, atau diterima oleh penerima yang sedang error → pertahankan operasi sebagai sumber kebenaran pemulihan yang dibatasi waktu.

Pertanyaan Lanjutan

Pertanyaan Lanjutan 1: Transaksi database telah di-commit, tetapi respons 202 hilang. Apa yang terjadi jika klien mengirimkan permintaan lagi?

Klien menggunakan kembali Idempotency-Key yang asli. Server menemukan operasi berdasarkan tenant, endpoint, dan key, mengonfirmasi bahwa sidik jari permintaan cocok, lalu memutar ulang representasi saat ini dan Location tanpa memasukkan operasi baru atau catatan outbox lainnya. Jika key cocok tetapi permintaannya berbeda, kembalikan conflict dan minta key baru. Pengujian harus membuktikan bahwa hanya ada satu baris operasi dan satu hasil yang terlihat meskipun pengiriman antrean terduplikasi.

Pertanyaan Lanjutan 2: Operasi sudah selesai 90%. Pembatalan dan commit hasil tiba secara bersamaan. Status mana yang menang?

Tentukan transisi yang sah sebelumnya dan gunakan version-conditional update untuk memilih satu pemenang. Jika transaksi hasil melakukan commit dari running ke succeeded terlebih dahulu, pembatalan yang datang kemudian akan membaca dan mengembalikan status terminal succeeded. Jika pembatalan mencapai status cancel_requested terlebih dahulu, worker akan memeriksa apakah penyelesaian masih diizinkan sebelum melakukan commit. Tahap yang tidak dapat diubah dapat membuat cancel_requested secara sah berakhir di succeeded atau failed; kontrak tidak dapat menjanjikan rollback mutlak.

Pertanyaan Lanjutan 3: Progres tidak dapat diperkirakan, tetapi manajer produk bersikeras menampilkan persentase. Apa yang Anda kembalikan?

Jelaskan bahwa persentase rekayasa menciptakan ekspektasi palsu. Tampilkan fase yang telah selesai, fase saat ini, heartbeat terakhir, dan rentang perkiraan non-mengikat yang diambil dari eksekusi historis. Kembalikan completedUnits / totalUnits hanya jika total beban kerja bersifat stabil. Jika fase-fase individual dapat diukur, tampilkan progres di dalam setiap fase alih-alih merata-ratakan fase dengan bobot komputasi yang berbeda.

Pertanyaan Lanjutan 4: Mitra integrasi menolak melakukan polling. Haruskah API hanya menyediakan webhook?

Webhook dapat mengurangi latensi dan pembacaan pada skenario normal, tetapi tidak bisa menjadi satu-satunya mekanisme pemulihan. Callback rentan mengalami masalah DNS, sertifikat, firewall, rotasi signing key, duplikasi, dan masalah urutan data. Berikan tanda tangan digital dan coba kirim ulang pengiriman webhook, sertakan ID operasi serta versi, dan wajibkan penerima melakukan deduplikasi. Mitra dapat melakukan rekonsiliasi melalui operation resource setelah melewatkan sebuah event. Browser tanpa endpoint callback yang stabil tetap menggunakan polling atau SSE.

Pertanyaan Lanjutan 5: Satu laporan menghasilkan file berukuran 20 GiB. Haruskah operation API langsung mengembalikan URL unduhan?

Operasi harus mengembalikan referensi ke result resource. Lakukan otorisasi tenant dan pemanggil sekali lagi sebelum menerbitkan kredensial unduhan 15 menit seperti pada kasus ini. Jangan menyimpan URL object-store jangka panjang di dalam data operasi. File bertahan selama 24 jam sedangkan metadata operasi bertahan selama 7 hari, sehingga setelah file kedaluwarsa, operasi masih dapat menyatakan bahwa eksekusi berhasil, artefak telah kedaluwarsa, dan pembuatan ulang tersedia.

Pertanyaan Lanjutan 6: Lalu lintas pemeriksaan status tumbuh lebih besar daripada lalu lintas eksekusi. Apa yang pertama kali Anda ubah?

Pertama, pastikan klien mematuhi Retry-After, exponential backoff, batas atas (cap), dan jitter. Kemudian aktifkan conditional requests berbasis ETag, kuota tenant, dan pembatasan laju permintaan (rate limiting). Browser yang membutuhkan latensi lebih rendah dapat mengonsolidasikan pembaruan melalui SSE, dan pemanggil server dapat menggunakan webhook, sementara pembacaan status berfrekuensi rendah tetap tersedia. Berikan jitter pada interval yang disarankan juga agar lonjakan pengiriman pukul 09:00 tidak menjadi lonjakan periodik yang tersinkronisasi pada endpoint status.