𝗔 𝗦𝘂𝗰𝗰𝗲𝘀𝘀𝗳𝘂𝗹 𝗣𝗮𝘆𝗺𝗲𝗻𝘁 𝗧𝗵𝗮𝘁 𝗡𝗲𝘃𝗲𝗿 𝗕𝗲𝗰𝗮𝗺𝗲 𝗮 𝗕𝗼𝗼𝗸𝗶𝗻𝗴
ಒಬ್ಬ ಗ್ರಾಹಕರು ಪಾವತಿಸಿದರು. Razorpay ಯಶಸ್ಸನ್ನು ತೋರಿಸಿತು. Webhook ಒಂದು HTTP 200 ಅನ್ನು ಕಳುಹಿಸಿತು. ಪಾವತಿಯನ್ನು ಕ್ಯಾಪ್ಚರ್ (captured) ಮಾಡಲಾಯಿತು.
ಆದರೂ ಬುಕಿಂಗ್ "confirming" ಹಂತದಲ್ಲೇ ಸಿಲುಕಿಕೊಂಡಿತು.
ಯಾವುದೇ ದೋಷಗಳು (errors) ಕಾಣಿಸಲಿಲ್ಲ. ಯಾವುದೇ ಎಕ್ಸೆಪ್ಶನ್ಗಳು (exceptions) ಕೋಡ್ ಅನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡಲಿಲ್ಲ. ಯಾವುದೇ ಅಲರ್ಟ್ಗಳು ಬರಲಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಮೆಟ್ರಿಕ್ ಕೂಡ ವ್ಯವಸ್ಥೆಯು ಸುಸ್ಥಿತಿಯಲ್ಲಿದೆ ಎಂದು ತೋರಿಸುತ್ತಿತ್ತು.
ಆದರೆ ಗ್ರಾಹಕರಿಗೆ ಏನೂ ಸಿಗಲಿಲ್ಲ. ಕ್ರಿಯೇಟರ್ಗೆ ಯಾವುದೇ ಬುಕಿಂಗ್ ಇರಲಿಲ್ಲ.
ಹಣವನ್ನು ಸ್ವೀಕರಿಸುವುದು ಸುಲಭ. ಪ್ರತಿಯೊಂದು ಪಾವತಿಯು ಬುಕಿಂಗ್ ಆಗುವಂತೆ ಮಾಡುವುದು ನಿಜವಾದ ಸವಾಲು.
ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಈ ಹರಿವನ್ನು (flow) ಸೂಚಿಸುತ್ತವೆ:
- Webhook ಇವೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ
- Webhook ಬುಕಿಂಗ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ
ಇದು ಅಪಾಯಕಾರಿ. ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ (business logic) Webhook ಒಳಗಿದ್ದರೆ, ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ಅದರ ವಿತರಣೆಯ ಯಶಸ್ಸಿನ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಿರುತ್ತೀರಿ. Webhooks ರಿಟ್ರೈಗಳು (retries), ಡೂಪ್ಲಿಕೇಟ್ಗಳು (duplicates) ಮತ್ತು ಭಾಗಶಃ ವೈಫಲ್ಯಗಳನ್ನು ಎದುರಿಸುತ್ತವೆ.
ಈ ಕಾರ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ನಾವು ನಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಬದಲಾಯಿಸಿದೆವು. Webhooks ಈಗ ಕೇವಲ ಇವೆಂಟ್ಗಳನ್ನು ದಾಖಲಿಸುತ್ತವೆ. ಅವು ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ.
ನಾವು ಮೂರು ಟೇಬಲ್ಗಳೊಂದಿಗೆ ಒಂದು ಇವೆಂಟ್ ಲೆಡ್ಜರ್ ಅನ್ನು ಪರಿಚಯಿಸಿದೆವು:
- payment_orders: ಪ್ರೊವೈಡರ್ನ ಸತ್ಯಾಂಶ (The provider truth)
- payment_events: ಬದಲಾಯಿಸಲಾಗದ ಇವೆಂಟ್ ಲೆಡ್ಜರ್ (The immutable event ledger)
- bookings: ಬಿಸಿನೆಸ್ ಸತ್ಯಾಂಶ (The business truth)
Webhook ಈಗ ಕೇವಲ ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡುತ್ತದೆ:
- ಸಿಗ್ನೇಚರ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು (Verify signature)
- ಇವೆಂಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು (Store event)
- 200 ಅನ್ನು ರಿಟರ್ನ್ ಮಾಡುವುದು (Return 200)
ಇದು ವ್ಯವಸ್ಥೆಯನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. Webhook ವಿಫಲವಾದರೂ, ಇವೆಂಟ್ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ.
ಪಾವತಿಯ ಸ್ಥಿತಿ (payment state) ಮತ್ತು ಬುಕಿಂಗ್ ಸ್ಥಿತಿ (booking state) ವಿಭಿನ್ನವಾಗಿವೆ ಎಂದು ನಾವು ಕಲಿತೆವು. ಕ್ಯಾಪ್ಚರ್ ಮಾಡಲಾದ ಪಾವತಿಯು ಒಂದು ಇನ್ಪುಟ್ (input). ಕನ್ಫರ್ಮ್ ಆದ ಬುಕಿಂಗ್ ಒಂದು ಫಲಿತಾಂಶ (result). ಇವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವುದು ಹೊಂದಾಣಿಕೆಗಾಗಿ (reconciliation) ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ತನಿಖೆಯ ಸಮಯದಲ್ಲಿ, ನಮಗೆ ಒಂದು ಬಗ್ (bug) ಕಂಡುಬಂದಿತು. ಇವೆಂಟ್ಗಳು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಇದ್ದವು. ಪ್ರೊಸೆಸರ್ ಸುಸ್ಥಿತಿಯಲ್ಲಿತ್ತು. Webhook ಸುಸ್ಥಿತಿಯಲ್ಲಿತ್ತು.
ಆದರೆ ಪ್ರೊಸೆಸರ್ ಎಂದಿಗೂ ಚಲಿಸಲಿಲ್ಲ. ಬಾಕಿ ಇರುವ ಇವೆಂಟ್ಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಲು ಫಂಕ್ಷನ್ ಅನ್ನು ಯಾರೂ ಟ್ರಿಗ್ಗರ್ ಮಾಡುತ್ತಿರಲಿಲ್ಲ.
Ingestion ಅನ್ನು processing ನಿಂದ ಬೇರ್ಪಡಿಸುವುದು (decoupling) ಉತ್ತಮ ವಿನ್ಯಾಸವಾಗಿದೆ. ಆದರೆ ಇದು ಒಂದು ಹೊಸ ಅಗತ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಏನಾದರೂ ಟ್ರಿಗ್ಗರ್ ಮಾಡಬೇಕು.
ನಾವು ಹಲವಾರು ಕೆಲಸಗಳನ್ನು ಮಾಡಲು ಒಂದು ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಜಾರಿಗೆ ತಂದೆವು:
- ಪಾವತಿ ಇವೆಂಟ್ಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡುವುದು
- ತಪ್ಪಿದ Webhooks ಅನ್ನು ಮರುಪಡೆಯುವುದು
- ಸಿಸ್ಟಮ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿಯನ್ನು (system consistency) ಪರಿಶೀಲಿಸುವುದು
ರಿಟ್ರೈ ಮಾಡುವಾಗ ದೋಷಗಳನ್ನು ತಡೆಯಲು, ನಾವು ಈ ಲಾಜಿಕ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ:
- ಪ್ರೊಸೆಸ್ ಆಗದ ಇವೆಂಟ್ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು
- ಮಲ್ಟಿಪಲ್ ವರ್ಕರ್ಸ್ಗಳಿಗೆ ಅವಕಾಶ ನೀಡಲು "SKIP LOCKED" ಬಳಸುವುದು
- ಡೂಪ್ಲಿಕೇಟ್ ವಿತರಣೆಗಳು ಏನನ್ನೂ ಮಾಡದಂತೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು
ಪ್ರತಿಯೊಂದು Webhook ಸರಿಯಾದ ಸಮಯಕ್ಕೆ ಬಂದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ವ್ಯವಸ್ಥೆಯು ದುರ್ಬಲವಾದ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ನಿಮ್ಮ ಕ್ಯೂ (queue) ಅನ್ನು ಖಾಲಿ ಮಾಡಲು ಯಾರೂ ಇಲ್ಲದಿದ್ದರೆ, ಕೆಲಸವು ಎಂದಿಗೂ ಮುಗಿಯದೆ ಕಾಯುತ್ತಿರುತ್ತದೆ.
ವಿಶ್ವಾಸಾರ್ಹತೆ ಎಂದರೆ ವಿಷಯಗಳು ವಿಫಲವಾದಾಗಲೂ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ನಿರ್ಮಿಸುವುದು.