Temu Duga Backend: Bagaimana Anda Mereka Bentuk API untuk Operasi Berjalan Lama (Long-Running Operations)?

Prompt dan Skop

Sebuah platform analitik B2B memerlukan API eksport laporan. Satu eksport mengambil masa 5 minit hingga 3 jam dan boleh menghasilkan fail sebesar 20 GiB. Perkhidmatan ini mungkin menerima 10,000 penghantaran sekitar jam 09:00 setiap hari. Pemanggil termasuk penyemak imbas dan perkhidmatan yang dikendalikan oleh syarikat lain. Get laluan API menutup permintaan segerak selepas 30 saat, jadi pemanggil mungkin mencuba semula apabila mereka tidak menerima respons.

Pengguna mesti dapat melihat sama ada kerja sedang berada dalam giliran (queued), sedang berjalan (running), berjaya (successful), atau gagal (failed). Mereka juga perlu meminta pembatalan selagi ia masih boleh dilakukan dan memuat turun hasil yang berjaya. Tempoh masa, saiz fail, waktu puncak, dan tamat masa adalah andaian kes temu duga, bukannya ambang industri. Pemetakan giliran (queue partitioning) berada di luar fokus utama soalan ini. Tugas teras adalah untuk mentakrifkan kontrak HTTP tak segerak yang kekal mudah difahami melalui percubaan semula, kegagalan proses (process crashes), dan perlumbaan keadaan (state races).

RFC 9110 menyatakan bahawa 202 Accepted bermaksud permintaan telah diterima untuk diproses tetapi pemprosesan belum selesai dan mungkin tidak akan berlaku. Respons tersebut sepatutnya menerangkan status semasa dan menunjuk ke pemantau status. Panduan temu duga REST API senior semasa juga meminta calon untuk mereka bentuk operasi berjalan lama, termasuk status, kegagalan, pembatalan, dan keidempotensian. Soalan ini sesuai untuk jurutera backend, jurutera platform API, dan jurutera full-stack senior yang mereka bentuk kontrak perkhidmatan, jadi kategori terasnya ialah backend.

Apa yang Dinilai oleh Penemu Duga

Pertama, adakah calon memahami sempadan 202? Ia tidak bermaksud "tugas latar belakang akan berjaya," dan kerja yang belum selesai bukanlah hasil akhir 200 OK. Jawapan yang mantap menolak permintaan tidak sah yang dapat dikesan serta-merta secara segerak, kemudian mengembalikan sumber operasi yang stabil selepas penerimaan yang tahan lama dan mendedahkan hasil pelaksanaan sebagai keadaan terkemudian.

Kedua, bolehkah calon memodelkan kerja berjalan lama sebagai sumber dan bukannya hanya mengembalikan ID mesej giliran? Sesuatu operasi memerlukan pemilik penyewa, cap jari permintaan (request fingerprint), keadaan, kemajuan, hasil atau ralat, versi, masa penciptaan, dan masa luput. Mesin keadaannya mesti mentakrifkan peralihan yang dibenarkan, keadaan terminal, dan perlumbaan pembatalan.

Ketiga, adakah terdapat jurang di mana pelayan telah mengembalikan 202 tetapi kerja tersebut tidak pernah dimasukkan ke dalam giliran? Rekod operasi dan kerja-untuk-diterbitkan harus dikekalkan dalam satu transaksi, kemudian penerbit outbox boleh memasukkannya ke dalam giliran. Pengguna (consumers) dan peringkat pelaksanaan masih memerlukan keidempotensian kerana penghantaran sekurang-kurangnya sekali (at-least-once delivery), ranapan pekerja (worker crashes), dan pengambilalihan pajakan (lease takeover) boleh menduplikasi kerja.

Keempat, bolehkah kontrak klien bertahan dalam trafik sebenar? Location memberitahu klien di mana untuk memeriksa status. Retry-After, backoff, jitter, dan permintaan bersyarat mengawal pengundian. Webhook yang ditandatangani boleh memberitahu pemanggil pelayan-ke-pelayan, dan SSE boleh mengemas kini penyemak imbas, tetapi kedua-duanya tidak menggantikan sumber operasi yang boleh disoal untuk pemulihan.

Akhir sekali, penemu duga ingin mendengar strategi keselamatan dan pengesahan. ID yang tidak dapat diteka bukanlah pengesahan kebenaran peringkat objek, dan URL hasil tidak boleh memintas sempadan penyewa. Jawapan yang mantap menguji kehilangan respons penerimaan, penghantaran pendua, kegagalan penerbitan, ranapan pekerja, perlumbaan pembatalan-penyiapan, lonjakan pengundian, dan pembersihan luput.

Soalan untuk Dijelaskan Terlebih Dahulu

• Apakah yang mesti disahkan secara segerak? Identiti, kebenaran penyewa, bentuk permintaan, kewujudan input, dan pelanggaran kuota yang ketara harus disemak sebelum penerimaan. Jika kelengkapan data hanya boleh diketahui selepas imbasan berbilang jam, itu adalah kegagalan pelaksanaan tak segerak, bukannya janji yang dibuat semasa penerimaan.
• Adakah permintaan pendua bermaksud percubaan semula atau operasi bebas kedua? Apabila pemanggil menyediakan Idempotency-Key, penyewa, titik akhir, kunci, dan cap jari permintaan yang sama harus memainkan semula satu operasi. Pemanggil yang sengaja memerlukan dua eksport yang serupa mesti menggunakan dua kunci.
• Adakah kemajuan boleh diukur? Jika jumlah bilangan petak (partitions) diketahui, laporkan unit yang telah selesai dan jumlah unit. Jika ia tidak dapat dianggarkan, laporkan fasa dan denyutan jantung (heartbeat) terakhir daripada mereka-reka peratusan yang tersasar ke 99%.
• Apakah jenis sumber bagi hasil tersebut? Hasil yang kecil boleh dibenamkan dalam respons operasi. Fail yang besar harus menjadi sumber dilindungi yang berasingan. Kes ini menggunakan kelayakan muat turun jangka pendek dan tempoh pengekalan berasingan untuk metadata operasi, objek hasil, dan kelayakan muat turun.
• Apakah yang dijanjikan oleh pembatalan? Adakah ia hanya menghentikan kerja masa hadapan, atau adakah ia mesti membatalkan kesan sampingan yang telah dilakukan? Jika langkah-langkah tidak boleh diundur, kontrak mesti mentakrifkan pembatalan usaha terbaik (best-effort cancellation), pampasan, output separa, dan kemungkinan keadaan akhir.
• Saluran pemberitahuan manakah yang boleh diterima oleh pemanggil? Penyemak imbas biasanya tidak boleh mengehoskan titik akhir panggilan balik, jadi pengundian atau SSE adalah sesuai. Pemanggil pelayan-ke-pelayan boleh menggunakan webhook. Kekangan rangkaian dan matlamat kependaman mengubah saluran pemberitahuan, tetapi sumber operasi kekal sebagai punca kebenaran (source of truth).
• Bolehkah operasi selari berkonflik? Bolehkah satu konfigurasi laporan dieksport secara serentak? Apa yang berlaku apabila konfigurasi itu dikemas kini atau dipadam semasa pelaksanaan? Jawapannya menentukan sama ada perlu menyiri (serialize), mengambil snapshot input, menolak konflik, atau membiarkan versi lama selesai.
• Berapa lama keadaan dikekalkan? Kes ini mengekalkan operasi terminal selama 7 hari, objek hasil selama 24 jam, dan setiap kelayakan muat turun selama 15 minit. Ini adalah pilihan kontrak-produk yang harus berubah mengikut keperluan audit, kos, dan keupayaan untuk menjana semula hasil.

Kerangka Jawapan 30 Saat

“Saya akan mengasingkan pelaksanaan daripada permintaan HTTP, tetapi saya tidak akan mengembalikan ID tugas sahaja. Titik akhir penghantaran mengesahkan kebenaran dan ralat yang dapat dikesan serta-merta, kemudian menulis rekod operasi dan rekod outbox dalam satu transaksi. Setelah komit, ia mengembalikan 202, Location, dan selang pengundian yang dicadangkan. Sumber operasi yang dibenarkan mendedahkan keadaan stabil, kemajuan sebenar, ralat berstruktur, dan pautan hasil. Kunci keidempotensian dan permintaan yang sama memainkan semula operasi yang sama. Pekerja memproses mengikut ID operasi secara idempoten, manakala syarat versi melindungi peralihan keadaan. Pengundian menggunakan Retry-After, backoff, dan jitter; pemanggil pelayan boleh menambah webhook yang ditandatangani; pembatalan memasuki cancel_requested dan menyelesaikan perlumbaannya dengan penyiapan. Saya kemudiannya akan menyuntik kehilangan respons, mesej pendua, ranapan pekerja, perlumbaan pembatalan, dan kelupaan untuk membuktikan tiada tugas hantu (ghost jobs), hasil kelihatan yang mendua, atau muat turun tanpa kebenaran.”

Pendalaman Langkah demi Langkah

Pertama, takrifkan dua sumber. Permintaan eksport menyatakan hasil yang ingin dibuat oleh pengguna, manakala sumber operasi mewakili kitaran hayat pelaksanaan ini. Penghantaran boleh menjadi POST /v1/report-exports, dan status boleh menjadi GET /v1/report-operations/{operation_id}. Respons penerimaan boleh berbentuk:

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 bahawa pemprosesan telah diterima. Tolak permintaan yang salah bentuk, pemanggil tanpa kebenaran, atau input yang tidak wujud dengan 4xx yang sesuai dan jangan cipta operasi. Kekalkan kegagalan perniagaan yang memerlukan pengiraan mahal dalam sumber operasi. Location dan Retry-After adalah sebahagian daripada kontrak klien API ini; RFC 9110 tidak memerlukan setiap respons 202 untuk menggunakan kedua-dua pengepala.

Kedua, takrifkan rekod operasi dan mesin keadaan. Rekod minimum mengandungi id, tenant_id, idempotency_key, request_fingerprint, status, kemajuan, rujukan hasil, ralat berstruktur, version, cap masa penciptaan dan kemas kini, serta expires_at. Set peralihan yang disyorkan ialah:

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

Pembatalan dan penyiapan boleh berlumba, jadi cancel_requested bukan terminal. Pekerja mengkomit hasil dengan kemas kini bersyarat ke atas version dan keadaan terdahulu yang dibenarkan; hanya satu peralihan yang menang. Jika kesan sampingan sudah tidak boleh diundur, pembatalan akhirnya mungkin menjadi succeeded atau failed. Jangan reka canceled semata-mata untuk memadankan label butang. Perwakilan status boleh kelihatan 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 kemajuan ini hanya apabila unit kerja mempunyai penyebut sebenar. Pelaksanaan yang gagal masih boleh mengembalikan 200 apabila operasi itu sendiri berjaya dibaca, dengan kegagalan diwakili oleh keadaan terminal dan error berstruktur: pembacaan status berjaya manakala pelaksanaan yang diwakili gagal. Pasukan yang sebaliknya memetakan kegagalan pelaksanaan kepada 4xx daripada titik akhir status mesti menggunakan konvensyen tersebut secara konsisten merentas setiap SDK dan bukannya mencampurkan kedua-dua maksud.

Ketiga, jadikan penerimaan, percubaan semula, dan pelaksanaan tepat. Letakkan kekangan unik pada (tenant_id, route, idempotency_key) dan simpan cap jari permintaan kanonikal. Kunci dan cap jari yang sama mengembalikan operasi sedia ada dan keadaan semasa. Kunci yang sama dengan cap jari berbeza mengembalikan konflik eksplisit, menghalang penggunaan semula kunci secara tidak sengaja untuk laporan lain. Kekalkan rekod keidempotensian sekurang-kurangnya selama klien boleh mencuba semula secara sah dan selaraskannya dengan pengekalan operasi.

Sisipkan operasi dan peristiwa outbox dalam satu transaksi pangkalan data, kemudian kembalikan 202. Penerbit berasingan menghantar peristiwa outbox ke giliran dan mungkin menghantarnya lebih daripada sekali. Pengguna menyahduplikasi mengikut ID operasi. Setiap peringkat pelaksanaan juga memerlukan penulisan idempoten atau token pemagaran (fencing token) supaya ranapan pekerja selepas penulisan luaran, diikuti dengan pengambilalihan, tidak menghasilkan dua hasil yang kelihatan. Jawapan API perlu membuktikan sempadan penerimaan-ke-giliran; ia tidak perlu menghasilkan semula reka bentuk penjadual yang lengkap.

Keempat, kawal trafik status dan pemberitahuan. Respons status awal dan terkemudian menyediakan Retry-After yang munasabah. Klien menggunakan backoff eksponen dengan had dan jitter, manakala pelayan menyokong ETag dan permintaan bersyarat untuk mengelakkan penghantaran semula badan yang tidak berubah. Jika bacaan status melebihi kuota, kembalikan maklumat had kadar (rate-limit) daripada membenarkan 10,000 pemanggil membuat pengundian setiap saat.

Penyemak imbas yang memerlukan kemajuan kependaman rendah boleh melanggan SSE dan masih boleh membuat pertanyaan mengikut ID operasi selepas terputus sambungan. Pemanggil pelayan boleh mendaftarkan webhook yang ditandatangani; penghantar mencuba semula, dan penerima menyahduplikasi. Kedua-dua saluran tolak boleh hilang, tertangguh, atau diduplikasi, jadi sumber operasi kekal sebagai punca kebenaran untuk pemulihan dan penyelarasan. Sekiranya berjaya, badan operasi boleh memautkan kepada hasil. Jika API sebaliknya mengalihkan ke sumber hasil yang berbeza, dokumentasikan semantik 303 dan sahkan bahawa SDK tidak memainkan semula POST asal di lokasi hasil tersebut.

Kelima, kendalikan pengesahan kebenaran, pembatalan, dan pengekalan. Setiap bacaan status, pembatalan, dan pengambilan hasil melakukan pengesahan kebenaran peringkat objek ke atas tenant_id, identiti pemanggil, dan kebenaran operasi. ID rawak menjadikan enumerasi lebih sukar tetapi ia bukan pengesahan kebenaran. Perkhidmatan muat turun mengesahkan pemilikan hasil sekali lagi, kemudian mengeluarkan kelayakan 15 minit yang dipilih untuk kes ini. Respons operasi tidak pernah menyimpan URL awam jangka panjang.

DELETE /v1/report-operations/{id} boleh menyatakan permintaan pembatalan. Jika pembatalan boleh dilakukan, kembalikan perwakilan cancel_requested semasa untuk menunjukkan ia telah diterima. Jika ia mustahil atau operasi sudah berada dalam keadaan terminal, kembalikan respons stabil yang selamat untuk dicuba semula. Pekerja memeriksa penanda pembatalan pada sempadan peringkat, melangkau langkah masa hadapan, dan mengalih keluar objek sementara. Kesan luaran yang telah dilakukan mengikut peraturan pampasan yang telah ditetapkan. Padamkan operasi terminal selepas 7 hari. ID luput yang diketahui boleh mengembalikan 410 Gone, manakala ID yang tidak diketahui atau tidak dibenarkan boleh mengembalikan 404 mengikut dasar pendedahan.

Keenam, sahkan kegagalan dan bukan sekadar laluan bahagia (happy path). Lindungi sekurang-kurangnya kes-kes ini: pelayan mengkomit tetapi kehilangan respons 202, dan percubaan semula hanya boleh mendapatkan operasi yang sama; penerbit outbox ranap sebelum atau selepas menghantar, dan kerja akhirnya wujud dengan satu hasil yang kelihatan; pekerja kehilangan pengakuannya selepas menulis hasil, dan penggantinya tidak boleh menulis ganti keadaan terminal; pembatalan dan penyiapan tiba bersama, dan hanya satu keadaan terminal yang sah muncul; pengundian status yang tidak berubah mematuhi backoff dan permintaan bersyarat; status rentas penyewa, pembatalan, dan muat turun semuanya gagal; metadata, hasil, dan kunci keidempotensian luput mengikut kontrak.

Peraturan keputusan yang boleh diguna semula ialah: 202 menyelesaikan penantian sambungan, sumber operasi menyelesaikan kebolehcerapan, dan penerimaan atomik serta mesin keadaan idempoten menyelesaikan ketepatan.

Contoh Jawapan Berkualiti Tinggi

“Mula-mula saya akan mengasingkan kejayaan penerimaan daripada kejayaan pelaksanaan. Operasi ini boleh mengambil masa 3 jam dan tidak boleh menduduki sambungan get laluan yang bertahan selama 30 saat. Oleh itu, POST /v1/report-exports menyemak identiti, kebenaran penyewa, bentuk permintaan, kewujudan input, dan pelanggaran kuota yang ketara. Ia kemudian mencipta rekod operasi dan outbox dalam satu transaksi dan hanya mengembalikan 202 selepas komit. Respons tersebut merangkumi Location untuk sumber operasi dan Retry-After untuk bacaan status pertama. Respons 202 tidak menjanjikan bahawa laporan itu akan berjaya.

Operasi menyimpan pemilikan penyewa, kunci keidempotensian, cap jari permintaan, keadaan, kemajuan yang boleh disahkan, hasil atau ralat, versi, dan masa luput. Keadaan beralih daripada queued ke running dan kemudian ke succeeded atau failed. Pembatalan pada mulanya memasuki cancel_requested kerana pekerja mungkin sedang mengkomit hasil pada masa yang sama. Di bawah penyewa dan titik akhir yang sama, kunci keidempotensian dan permintaan yang sama mengembalikan satu operasi; kunci yang sama dengan permintaan yang berbeza menghasilkan konflik. Oleh itu, respons 202 yang hilang tidak boleh mencipta laporan kedua apabila klien mencuba semula.

Saya mengandaikan penghantaran giliran sekurang-kurangnya sekali (at-least-once). Outbox mungkin menerbitkan dua kali, pengguna menyahduplikasi pada ID operasi, dan penulisan luaran dalam setiap peringkat adalah idempoten atau dipagari. Kemas kini keadaan menyertakan syarat versi supaya pekerja lapuk tidak boleh menulis ganti hasil selepas pajakannya diambil alih. Kegagalan sebelum penerimaan mengembalikan 4xx serta-merta. Kegagalan semasa pelaksanaan disimpan sebagai keadaan terminal dan ralat berstruktur, yang membolehkan klien membezakan kegagalan rangkaian, kegagalan membaca status, dan kegagalan pelaksanaan laporan.

Klien membuat pengundian mengikut Retry-After dengan backoff eksponen dan jitter, dan titik akhir status menyokong ETag. Penyemak imbas boleh menggunakan SSE untuk kemajuan langsung dan perkhidmatan rakan kongsi boleh menggunakan webhook yang ditandatangani, tetapi kedua-duanya pulih melalui sumber operasi selepas terputus sambungan atau menerima pemberitahuan pendua. Fail hasil tidak pernah mempunyai URL awam. Titik akhir muat turun mengesahkan kebenaran sekali lagi dan mengeluarkan kelayakan 15 minit. Dalam kes ini, operasi terminal wujud selama 7 hari dan fail selama 24 jam, dan peraturan kelupaan tersebut adalah kontrak awam.

Akhir sekali, saya akan menguji respons yang hilang selepas komit, penghantaran outbox berulang, ranapan pekerja selepas menulis hasil, perlumbaan pembatalan-penyiapan, 10,000 pemanggil mengundi bersama, dan akses rentas penyewa. Lulus bermakna lebih daripada sekadar berjaya sekali di latar belakang: kegagalan ini tidak boleh mencipta tugas hantu, hasil kelihatan yang mendua, peralihan haram, atau muat turun tanpa kebenaran.”

Kesilapan Biasa

• Memulakan bebenang dalam memori selepas mengembalikan 202 → permulaan semula proses meninggalkan kerja yang tidak akan dapat ditemui, dan penerimaan tidak atomik dengan pelancaran → kekalkan operasi dan outbox sebelum mengakui penerimaan.
• Menganggap 202 sebagai kejayaan akhir → HTTP secara jelas membenarkan pemprosesan tidak pernah berlaku atau gagal → dedahkan hasil akhir, ralat, dan pemantau status dalam kontrak terkemudian.
• Hanya mengembalikan ID mesej giliran → ia tidak mempunyai pemilikan penyewa, keadaan stabil, ralat, hasil, dan pengekalan → cipta sumber operasi berasingan yang dibenarkan.
• Mengundi sekali setiap saat secara berterusan → puncak penghantaran menjadi puncak bacaan yang berterusan → sediakan Retry-After dan gunakan backoff, jitter, ETag, serta kuota.
• Menggunakan ID operasi rawak sebagai pengesahan kebenaran → log yang bocor, entri sejarah penyemak imbas, atau pautan dalaman masih memberikan akses rentas penyewa → sahkan kebenaran bagi setiap bacaan status, pembatalan, dan pengambilan hasil.
• Menyimpan kunci keidempotensian hanya dalam kunci Redis jangka pendek → kelupaan kunci, ranapan, dan main semula hasil masih boleh mencipta operasi pendua → gunakan kekangan keunikan yang tahan lama, cap jari permintaan, dan respons yang boleh dimainkan semula.
• Menandakan dibatalkan sebaik sahaja pengguna mengklik → pekerja mungkin telah melakukan kesan yang tidak boleh diundur → masuki cancel_requested terlebih dahulu dan biarkan peralihan bersyarat serta pampasan menentukan keadaan terminal yang sah.
• Sentiasa mereka-reka peratusan → fasa yang tidak dapat diramalkan terhenti pada 99% dan mengelirukan pemanggil → laporkan unit yang selesai apabila boleh diukur, jika tidak laporkan fasa dan masa kemas kini.
• Memadamkan operasi selepas webhook berjaya → pemberitahuan boleh hilang, diduplikasi, atau diterima oleh penerima yang rosak sementara → kekalkan operasi sebagai punca kebenaran pemulihan yang terikat masa.

Soalan Susulan

Susulan 1: Transaksi pangkalan data telah dikomit, tetapi respons 202 telah hilang. Apakah yang berlaku apabila klien menghantar semula?

Klien menggunakan semula Idempotency-Key yang asal. Pelayan mencari operasi mengikut penyewa, titik akhir, dan kunci, mengesahkan bahawa cap jari permintaan sepadan, dan memainkan semula perwakilan semasa serta Location tanpa menyisipkan rekod operasi atau outbox yang lain. Jika kunci sepadan tetapi permintaan berbeza, kembalikan konflik dan minta kunci baharu. Ujian mesti membuktikan bahawa terdapat satu baris operasi dan satu hasil yang kelihatan walaupun penghantaran giliran diduplikasi.

Susulan 2: Operasi sudah 90% selesai. Pembatalan dan komit hasil tiba bersama. Keadaan mana yang menang?

Takrifkan peralihan yang sah lebih awal dan gunakan kemas kini bersyarat versi untuk memilih satu pemenang. Jika transaksi hasil mengkomit running kepada succeeded terlebih dahulu, pembatalan terkemudian membaca dan mengembalikan keadaan terminal succeeded. Jika pembatalan mencapai cancel_requested terlebih dahulu, pekerja menyemak sama ada penyiapan masih dibenarkan sebelum komit. Peringkat yang tidak boleh diundur boleh menjadikan cancel_requested berakhir secara sah dalam succeeded atau failed; kontrak tidak boleh menjanjikan pengunduran mutlak (absolute rollback).

Susulan 3: Kemajuan tidak dapat dianggarkan, tetapi pihak produk berkeras mahukan peratusan. Apakah yang anda kembalikan?

Jelaskan bahawa peratusan yang direka-reka mencipta jangkaan palsu. Tunjukkan fasa yang telah selesai, fasa semasa, denyutan jantung terakhir, dan julat tidak mengikat yang diperoleh daripada larian sejarah. Kembalikan completedUnits / totalUnits hanya apabila jumlah beban kerja adalah stabil. Jika fasa individu boleh diukur, tunjukkan kemajuan dalam setiap fasa dan bukannya mempuratakan fasa yang mempunyai kos berbeza.

Susulan 4: Rakan kongsi enggan membuat pengundian. Patutkah API hanya mendedahkan webhook?

Webhook boleh mengurangkan kependaman dan bacaan laluan biasa, tetapi ia tidak boleh menjadi satu-satunya mekanisme pemulihan. Panggilan balik menghadapi kegagalan DNS, sijil, tembok api, giliran kunci menandatangani, penduaan, dan susunan. Tandatangani dan cuba semula penghantaran webhook, sertakan ID operasi dan versi, serta wajibkan penyahduplikasian penerima. Rakan kongsi boleh membuat penyelarasan melalui sumber operasi selepas peristiwa terlepas. Penyemak imbas tanpa titik akhir panggilan balik yang stabil terus menggunakan pengundian atau SSE.

Susulan 5: Satu laporan menghasilkan fail bersaiz 20 GiB. Patutkah API operasi mengembalikan URL muat turun secara terus?

Operasi harus mengembalikan rujukan sumber hasil. Sahkan kebenaran penyewa dan pemanggil sekali lagi sebelum mengeluarkan kelayakan muat turun 15 minit kes ini. Jangan simpan URL storan objek jangka panjang dalam operasi. Fail ini wujud selama 24 jam manakala metadata operasi wujud selama 7 hari, jadi selepas fail luput operasi masih boleh menyatakan bahawa pelaksanaan telah berjaya, artifak telah luput, dan penjanaan semula tersedia.

Susulan 6: Trafik pertanyaan status berkembang lebih besar daripada trafik pelaksanaan. Apakah yang anda ubah dahulu?

Mula-mula sahkan bahawa klien mematuhi Retry-After, backoff eksponen, had, dan jitter. Kemudian dayakan permintaan bersyarat berasaskan ETag, kuota penyewa, dan pengehadan kadar. Penyemak imbas yang memerlukan kependaman lebih rendah boleh menyatukan kemas kini melalui SSE, dan pemanggil pelayan boleh menggunakan webhook, manakala bacaan status frekuensi rendah kekal tersedia. Lakukan jitter pada selang masa yang dicadangkan juga supaya puncak penghantaran 09:00 tidak menjadi puncak berkala yang disegerakkan pada titik akhir status.