Napravio sam SaaS za automatsko praćenje neplaćenih računa – par tehničkih problema na koje sam naišao
Radim na jednom manjem SaaS projektu koji sam nazvao DueChat. Ideja je da sistem automatski prati račune koji nisu plaćeni i šalje follow-up poruke prema definisanoj logici.
Tehnički zanimljiv deo mi zapravo nije slanje emaila, već kako odlučiti kada i šta poslati.
Trenutno imam nekoliko stanja za svaki račun, npr.:
pending → due → overdue → reminder → paid
Iznad toga postoji scheduler koji proverava račune kojima je potrebno izvršiti neku akciju. Nisam hteo da se oslanjam na jedan veliki cron koji samo "pošalji sve što je dospelo", jer brzo dolaziš do problema sa duplim slanjem, retry-jima i race conditionima.
Jedan od problema koji mi je bio zanimljiv je idempotency. Ako worker padne nakon slanja emaila, a pre nego što upiše da je akcija izvršena, sledeći worker ne sme ponovo poslati isti email.
Drugi deo je sama logika komunikacije. Nije isto poslati:
- prvi podsetnik dan nakon roka
- drugi podsetnik nekoliko dana kasnije
- ozbiljniji follow-up nakon dužeg kašnjenja
Zato sam odvojio invoice state od communication state, tako da mogu menjati pravila komunikacije bez menjanja osnovne logike računa.
Još jedan zanimljiv problem je tracking plaćanja. Sistem mora znati da prestane sa follow-upovima čim je račun plaćen, bez obzira na to da li je status promenjen ručno ili kroz neki budući payment/accounting integration.
Projekat mi je zanimljiv jer je na površini vrlo jednostavan, ali čim kreneš da automatizuješ nešto što uključuje novac i komunikaciju sa stvarnim ljudima, pojavljuje se dosta edge case-ova.
Ako je neko radio sličan sistem — posebno scheduler/queue arhitekturu za ovakve workflow-e — zanima me kako ste rešavali idempotency, retries i state management.