// ALL COMMITS

Semua postingan

Cerita dan sharing orang IT

+ NEW COMMIT
DOCS

Error timeout gaboleh dianggap langsung gagal

Error timeout itu error yang ambigu dan gaboleh langsung dianggap gagal sama kita. Kenapa? Karena timeout itu belom tentu gagal di server penerimanya. Timeout itu sebenernya cuman sistem yang terlalu lama nunggu response dari server yang ngeproses, karena treshold timeout untuk API biasa itu mungkin di 3-5 detik, kalau ada proses yang emang lebih berat bisa dipanjangin sampe 30 detik atau 1 menit tergantung kebutuhan. Nah, karena timeout itu cuman client/gateway yg kelamaan nunggu response, makanya gaboleh dianggap gagal. Karen server yg proses bisa jadi lagi overload atau ada error/flow yg ga ke handle bener yg nyebabin server ga balikin apa2. Karena kalo dianggap langsung gagal misal untuk API yang minta server untuk menambah atau mengedit sesuatu, itu hasilnya bisa kedobel. Kalo misalnya di sosial media aja mungkin masih ga masalah ya bisa tinggal dihapus postingannya kalo ke input dobel. Tapi kalo udah berurusan sama hal sensitif kayak uang misal di banking atau fintech ya ini bisa jadi masalah. Misal aja gue kirim uang Rp. 10,000 dari bank A ke bank B. Bank A gue kena timeout terus dia anggep itu sebagai gagal, otomatis duit gue dibalikin ke rekening gue. Padahal sebenernya bank B mungkin lagi overload aja jadinya prosesnya agak lebih lama tp sebenernya berhasil di proses. Karena gue liat di aplikasi transfernya gagal dan uang gue udah balik, yaudah gue coba transfer lagi aja. Ternyata gue transfer lagi dan berhasil. Berarti bank B udah masukin Rp. 20,000 ke rekening penerima, sedangkan gue cuman dikurangin Rp. 10,000 aja dari rekening gue. Berarti sisa Rp. 10,000 lagi ini ngambil dari mana? Ya berarti Rp. 10,000 ini dibayarin bank A dan berarti bank A rugi Rp. 10,000 Nah error timeout yang kayak gini biasanya dibiarin aja statusnya processing atau pending, dan nanti ada scheduler yang nanya ke bank B status terakhir dari transaksinya. Kalo sampe beberapa kali hit ternyata masih processing, berarti musti di settle secara manual biasanya.

OR@orang_it_kan·
DOCS

5 checklist backend yg biasa gue pake untuk project gue

Ada 5 checklist (sebenernya lebih sih) yg gue biasa pake sebelum sistem backend gue naikin ke production 1. Monitoring & observability Ini penting banget buat gue biar kalo ada kenapa2 gue bisa dengan gampang tracing dan cari tau masalahnya. Karena kalo ini ga ada, buat pinpoint masalahnya ada di code atau sistem yg mana itu bakal susah banget dan bakal nebak2. Ini yg biasa gue pake (versi lightweight 1 VPS ram 8Gb) - Logging: Grafana + Loki https://grafana.com/oss/loki/ - System: Netdata https://www.netdata.cloud/ - Observability: Grafana + Loki atau Glitchtip (versi lebih ringan dari Sentry) https://glitchtip.com/ Kalo service kalian microservice, bisa juga tambahin Application Performance Monitoring (APM) biar lebih jelas end to endnya errornya ada di service yg mana https://www.elastic.co/docs/solutions/observability/apm https://openobserve.ai/opentelemetry/ 2. Environment Segregation Sering banget gue liat developer junior sampe senior itu buat bedain environment itu di hardcode di codingan entah itu karena gatau atau karena males setupnya. Ini yg biasanya ngebuat deployment jadi salah2 karena lupa ganti environment. Padahal tinggal buat aja file .env, klo di docker ya bisa pake docker compose di servernya atau klo ga pake docker ya bisa dibuat dulu .env di folder projectnya. 3. Security Ini juga salah satu yg penting buat diperhatiin juga karena berkaitan sama data dan kelangsungan sistem. Hal yg biasa gue cek disini adalah authentication & authorization, rate limiting, input validation, sama secret management. 4. Backup & recovery Ini juga penting kalau amit2 database atau sistem kalian kenapa2 seenggaknya ada backup sebagai checkpoint data kalian jadi ga bener2 hilang semuanya. Biasanya gue ngebuat scheduler backup per jam dan juga per hari untuk snapshot server dan jg dump database. Jangan lupa dites jg backupnya berkala biar pas nanti mau beneran backupnya ga error 5. CI/CD deployment Ini penting jg biar ga ada human error pas deploy. Walaupun kayaknya kalian pikir bisa deploy manual sendiri lewat server dan prosesnya gampang, percayalah segampang2nya deploy manual akan ada saatnya kalian ngelakuin human error dan banyak waktu habis untuk ssh, ftp, dll. Selain deployment jg biar bisa ngecek kalo code kalian ada yg breaking lewat CI pipeline. Gue pernah buat tutorial simple CI/CD, bisa dicek disini https://www.tiktok.com/@orang.it.kan/video/7684223047905152277 Untuk CI/CD bisa pake tools macam2: - Jenkins - Github actions - Platform as a service (PaaS) Ini 5 checklist yg bisa ngebantu gue lebih gampang untuk bug fixing, deploy, dan backup kalo kenapa2. Ini yg ngebedain gue yg dulu maintain aplikasi client grasak grusuk dan sekarang yang lebih tenang kalo ada masalah

OR@orang_it_kan·· diedit
CHANGELOG

AI mau di rebranding jadi SI

Trump lg coba nge rebranding sebutan Artificial Intelligence jadi Super Intelligence (SI) pas lg pidato di United Nations General Assembly (UNGA) 22 September 2026. Katanya namanya misleading karena artificial persepsinya lebih ke "fake" padahal efek inteligencenya itu ga fake. Sampe mau dibuat efektif langsung semua dokumen US diubah jadi SI. Tujuan asli rebrandingnya apa sih belom tau, apa cuman asbun aja gangerti jg sih.

AI mau di rebranding jadi SI
OR@orang_it_kan·· diedit
LOG

Gara2 pemerintah India, pusing kepala gue -_-

Jadi gue punya beberapa client dimana mereka semua pake telegram untuk dapetin notif kalo ada payment yang masuk lewat aplikasi. Beberapa bulan yg lalu, ada client gue yg tiba2 complain kalo mereka ga nemu notif telegram tp di dashboard CMS ada pembelian di tanggal tersebut. Yaudah akhirnya gue cek dong, dan bener aja ada transaksi di hari itu tapi di grup telegram ga muncul notifnya. Akhirnya gue coba cek ke client2 gue yang pake telegram jg tapi mereka aman2 aja. Jadi gue bingung ini kenapa cuman 1 client ini aja yg masalah. Gue coba CURL dari server container dan server langsung jg dapet error koneksi ke telegram. Akhirnya gue ceklah ke X (twitter) lah, gue coba search aja ada ga orang yg complain klo telegram lg bermasalah. Gue ga nemu postingan apa2 soal telegram lg bermasalah. Gue coba cari latest post, eh ketemu ada 1 postingan yg bilang India telegramnya lg di blokir karena ada kebocoran pertanyaan ujian atau kunci jawaban gitu dan itu masif. NAH! Akhirnya gue baru ngeh masalahnya dimana. Untuk client ini gue inget banget servernya gue setup di India wkwkwk. Kenapa gue setnya di India? Kenapa ga di singapur atau Indonesia aja? Nah karena waktu itu server terdekat yg available untuk hostingan gue ini adalah di India. Gue udah bayar juga hostingan ini waktu itu, jadi ya mau gamau. Yaudah akhirnya gue coba puter otak gimana caranya biar ini telegram bisa jalan lg kan. Gue searching dan tanya AI dan katanya telegram punya mekanisme proxy untuk kasus2 pemblokiran kayak gini. Cuman implementasinya lumayan jelimet dan akhirnya gue gabisa implement. Jadinya yaudah gue coba proxy ke server gue yg ga kepake untuk client. Yaudah akhirnya gue buatlah API forwarder ke telegram dan si client ini gue tembak telegram hostnya kesana wkwkwk. Karena kalo gue musti pindahin server gue ke lokasi yg baru, bakal ribet dan pasti ada downtime karena gue harus setup servernya dari awal. Untungnya aman dan yaudah sekarang udah kembali ke sedia kala. Ini beritanya https://www.bbc.com/news/articles/cn074j04l3eo

OR@orang_it_kan·· diedit

orang.it.kan — ruang santai anak IT Indonesia.

Built for the community.