Dāvanu karšu ieviešana e-komercijā izskatās trivāla… līdz brīdim, kad tās jāintegrē ar maksājumiem, noliktavu un grāmatvedību 😬 Tad sākas nekonsekventi stāvokļi, dubultas validācijas un spoku atlikumi. Šeit ejam dziļāk. Kā uzbūvēt arhitektūru, kur dāvanu kartes internetā strādā deterministiski, auditējami un bez tehniskā parāda. Papildus pieskaramies drošībai (https://itpeople.lv/cik-drosas-ir-davanu-kartes-interneta-no-it-skatpunkta/) un reālām integrācijas niansēm.
Praktiska ietekme skaitļos
Pirms arhitektūras. Ātri sanity check ar skaitļiem.
Dubultas norakstīšanas izmaksas
Ja dienā ir 200 redeem pieprasījumi un 1% gadījumu retry rada dubultu norakstīšanu. 200 × 1% = 2 kļūdaini darījumi dienā. Vidējā karte 30 € dod 2 × 30 = 60 € dienā. Mēnesī ~ 1800 € noplūde, ja nav idempotences.
Nesinhronizēti atlikumi ERP
Ja ERP atpaliek par 0.5% no 10 000 € izlaisto karšu apjoma:
10 000 × 0.5% = 50 € neatbilstība
Auditā tas nozīmē manuālu korekciju stundas × cilvēkresurss.
Webhook dublikātu slodze
Pie 5000 notikumiem dienā un at-least-once piegādes:
pieņemsim 5% dublikāti → 250 lieki eventi
Ja apstrāde maksā 5 ms CPU, tas ir 1.25 s/dienā, nieks… līdz brīdim, kad pieaug x100.
Integrācijas slāņu sadalījums
Tipiska kļūda. Visu loģiku ielikt e-veikala backendā.
Rezultāts ir cieša sasaite un grūti refaktori.
Sadaliet domēnos:
- gift-card service (issuance, balance, redemption)
- checkout/maksājumu serviss
- ERP/grāmatvedības adapteris
Izveidojiet gift-card-service ar savu datu modeli (karte, atlikums, transakcijas). Nevis paļaujieties uz e-veikala tabulām. Tas dod izolāciju un skaidrus API kontraktus.
API kontrakti un versēšana
API jābūt idempotentam un versētam. Bez kompromisiem.
Idempotenti pieprasījumi
Redeem operācijai izmantojiet Idempotency-Key, lai retry nerada dubultu norakstīšanu.
- POST /redeem
- headers Idempotency-Key UUID
- body cardid, amount, orderid
Serveris glabā atslēgu un pie atkārtota pieprasījuma atgriež identisku rezultātu.
Versiju pārvaldība
Neplēsiet klientus ar breaking changes.
- /v1/redeem, /v2/redeem
- vai header-based versioning
Schema evolution > ātri hotfixi.
Webhook dizains praksē
Webhooki ātri pārvēršas par haosu, ja nav disciplīnas.
Piegādes garantijas
Pieņemiet at-least-once.
- notikumi var atkārtoties
- patērētājam jābūt idempotentam
Notikumu struktūra
Standartizējiet payload:
- event_type giftcard.redeemed
- event_id UUID
- occurred_at ISO8601
- data { cardid, amount, orderid }
Glabājiet event_id, lai izslēgtu dubultu apstrādi.
Datu sinhronizācija starp sistēmām
Šeit visbiežāk rodas drift un kāpēc cipari nesakrīt? moments 😅
Event driven pieeja
Publicējiet notikumus (Kafka, SQS u.c.):
- giftcard.issued
- giftcard.redeemed
- giftcard.refunded
ERP patērē un veido ledger ierakstus. Loose coupling, mazāk sāpju.
Periodiska reconcile
Pat ar eventiem vajag reconcile jobu:
- salīdzina atlikumus
- atrod neatbilstības
- ģenerē korekcijas
Bez šī agrāk vai vēlāk būs mums kaut kas nesakrīt.
Dubultas validācijas slazdi
Bieži validācija notiek gan checkoutā, gan gift-card servisā… ar atšķirīgiem noteikumiem.
Risinājums:
- viens source of truth
- checkout orkestrē
- gift-card serviss validē
- checkout uzticas atbildei
Pretējā gadījumā garantēti būs edge case konflikti.
Transakciju modelis bez ACID
Distributed ACID šeit parasti ir overkill.
Izmantojiet saga modeli:
- Rezervē summu (hold)
- Apstiprina maksājumu
- Finalizē redeem
Ja 2. solis failo → kompensācija (release hold).
Grāmatvedības integrācija
Dāvanu kartes = saistības (liability), nevis ieņēmumi.
Tehniski:
- issuance → debit cash, credit deferred revenue
- redeem → debit deferred revenue, credit revenue
ERP adapterim jāstrādā ar unikāliem event_id, lai nebūtu dublikātu.
Arhitektūras ieteikumi praksē
Vienots identifikators visur
Izmantojiet vienu order_id across sistēmām. Traceability kļūst daudz vienkāršāka.
Observability instrumenti
Ieviesiet:
- distributed tracing (OpenTelemetry)
- structured logs ar correlation_id
Bez šī debug būs minēšana.
Retry un kļūdu apstrāde
- exponential backoff
- dead-letter queue webhookiem
Pretējā gadījumā kļūdas pazūd.
Kur rodas tehniskais parāds
- biznesa loģika izkaisīta vairākos servisos
- webhook bez versijas un shēmas
- tieši DB savienojumi starp sistēmām
Šie trīs punkti = nākotnes refaktoru rēķins.
Reāls konteksts Latvijā
Latvijā pieaug uzsvars uz tehnoloģiju prasmēm, piemēram, Google MI apmācības. Tas tieši ietekmē to, kā tiek projektētas šādas integrācijas, vairāk event-driven, vairāk datu disciplīnas.
Arī finanšu sektorā (piemēram, kredītu sistēmās, kā redzams Netcredit.lv datos) konsekvence un auditējamība ir kritiska, tās pašas problēmas parādās arī dāvanu karšu risinājumos. Dubultas transakcijas, neatbilstoši atlikumi, retry edge case.
Lietošanas scenāriji praksē
Pat šķietami vienkāršā gadījumā, kā izvēloties Dāvanu kartes konkrētai auditorijai, backendā notiek:
- atlikuma pārvaldība
- validācija
- notikumu sinhronizācija
- grāmatvedības ieraksti
UI vienkāršs. Backend… ne tik ļoti.
Ko darīt tālāk
Ja plānojat ieviest vai refaktorēt. Atdaliet domēnus un veidojiet dedicated servisu, ieviesiet idempotentus API un eventus, pārejiet uz event-driven sinhronizāciju, pievienojiet reconcile procesus. Rezultātā iegūsiet sistēmu, kur dāvanu kartes internetā nav edge case, bet stabils, prognozējams komponents, kas iztur gan slodzi, gan auditu.