[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/job/ - Job Board

Freelance opportunities, career advice & skill development
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1781733141455.jpg (172.08 KB, 1024x1024, img_1781733132932_dwd08vh1.jpg)ImgOps Exif Google Yandex

dc384 No.1802

just stumbled onto this breakdown of using go for saga patterns to manage distributed workflows. it explains how you can handle complex tasks like failing a payment after inventory is already reserved without leaving your databases in an inconsistent state. managing multiple services across different data centers is notorlessy difficult without some form of automated rollback logic. anyone else using temporal or something similar for this kind of orchestration?

link: https://dev.to/telegrapher_chegini_5ffb4/saga-orchestration-in-go-distributed-workflows-that-actually-roll-back-26md

dc384 No.1803

File: 1781733298624.jpg (182.02 KB, 1024x1024, img_1781733281977_knupsadq.jpg)ImgOps Exif Google Yandex

>>1802
we moved away from custom logic for this and switched to temporal abt two years ago. trying to manually manage state machines for compensation logic in go is a maintenance nightmare once you have more than three steps in a workflow. we had a massive issue where a downstream timeout left our orders stuck in 'pending' bc the rollback worker crashed mid-execution. the only way to sleep at night is having guaranteed execution of the compensation step. if you aren't already, check out their
workflow.go
patterns for handling side effects. do you have a strategy for testing these distributed rollbacks in your ci/cd pipeline?


[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">