𝗦𝗼𝗹𝘃𝗶𝗻𝗴 𝗣𝗮𝘆𝗺𝗲𝗻𝘁 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻 𝗘𝗿𝗿𝗼𝗿𝘀
ಒಬ್ಬ ಗ್ರಾಹಕರು 2,000 ಡಾಲರ್ಗಳನ್ನು ಕಳೆದುಕೊಂಡರು. ಅವರ ಹಣಕಾಸು ಮುಖ್ಯಸ್ಥರು (finance lead) ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಹುಡುಕಲು ನಾಲ್ಕು ರಾತ್ರಿಗಳನ್ನು ಕಳೆದರು.
ಸಮಸ್ಯೆ 'ರಿಟ್ರೈ ಜಾಬ್' (retry job) ಇತ್ತು. ಸಿಸ್ಟಮ್ 120 ಪೇಮೆಂಟ್ಗಳನ್ನು ಎರಡು ಬಾರಿ ಪ್ರೊಸೆಸ್ ಮಾಡಿತು. ಇದು ಗ್ರಾಹಕರಿಂದ ಮತ್ತೆ ಹಣವನ್ನು ಪಡೆದುಕೊಳ್ಳಲಿಲ್ಲ. ಬದಲಾಗಿ, ಇದು ಲೆಡ್ಜರ್ಗೆ (ledger) ಕೇವಲ ಎರಡು ಬಾರಿ ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಿತು.
ನಾವು ಇದನ್ನು 'ಐಡೆಂಪೊಟೆನ್ಸಿ ಲೇಯರ್' (idempotency layer) ಮೂಲಕ ಸರಿಪಡಿಸಿದೆವು. ಇದು ಒಂದು ಪೇಮೆಂಟ್ ಕೇವಲ ಒಂದು ಬಾರಿ ಮಾತ್ರ ಪ್ರೊಸೆಸ್ ಆಗುವಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ.
ನಾವು ಇದನ್ನು ಈ ರೀತಿ ಮಾಡಿದೆವು:
- ದ್ವಿಗುಣ ವಿನಂತಿಗಳನ್ನು (double requests) ತಡೆಯಲು ನಾವು Redis lock ಅನ್ನು ಬಳಸಿದೆವು.
- ಬ್ಯಾಕಪ್ ಆಗಿ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಒಂದು unique index ಅನ್ನು ಸೇರಿಸಿದೆವು.
- ಗೇಟ್ವೇ ಹೆಸರು ಮತ್ತು ಟ್ರಾನ್ಸಾಕ್ಷನ್ ID ಯೊಂದಿಗೆ ಒಂದು ಕೀ (key) ಅನ್ನು ಬಳಸಿದೆವು.
ನಾವು ಎಕ್ಸ್ಚೇಂಜ್ ದರಗಳನ್ನು (exchange rates) ಸಹ ಸರಿಪಡಿಸಿದೆವು. ಸಿಸ್ಟಮ್ ಲೈವ್ ದರಗಳನ್ನು ಬಳಸುತ್ತಿತ್ತು. ದರಗಳು ವೇಗವಾಗಿ ಬದಲಾಗುತ್ತವೆ. ಇದು ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಕಾರಣವಾಯಿತು.
ಈಗ ಆರ್ಡರ್ ಪ್ರಾರಂಭವಾದಾಗ ನಾವು ದರವನ್ನು ಲಾಕ್ ಮಾಡುತ್ತೇವೆ. ಗ್ರಾಹಕರು ಒಂದು ಬೆಲೆಯನ್ನು ನೋಡುತ್ತಾರೆ. ಹಣಕಾಸು ತಂಡವು ಸಹ ಅದೇ ಬೆಲೆಯನ್ನು ನೋಡುತ್ತದೆ.
ನಾವು ದೈನಂದಿನ ವರದಿಯನ್ನು ಸಹ ತಯಾರಿಸಿದ್ದೇವೆ. ಇದು ಬ್ಯಾಂಕ್ CSV ಫೈಲ್ಗಳನ್ನು ನಮ್ಮ ದಾಖಲೆಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಇದರಿಂದ ಮಾಸಿಕ ಕೆಲಸವು 15 ಗಂಟೆಗಳಿಂದ 2 ಗಂಟೆಗಳಿಗೆ ಇಳಿಕೆಯಾಯಿತು.
ಎಕ್ಸೆಲ್ (Excel) ಮತ್ತು ತಡರಾತ್ರಿಯ ಕೆಲಸಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಪೇಮೆಂಟ್ ದೋಷಗಳು ವಿನ್ಯಾಸದ (design) ಸಮಸ್ಯೆಗಳಾಗಿವೆ.
ಡೇಟಾಬೇಸ್ ಇಂಡೆಕ್ಸ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ವ್ಯವಹಾರ ಬೆಳೆದಂತೆ Redis locks ಅನ್ನು ಸೇರಿಸಿ. ಪೇಮೆಂಟ್ ನೋಟಿಫಿಕೇಶನ್ ಕೇವಲ ಒಂದು ಬಾರಿ ಮಾತ್ರ ಬರುತ್ತದೆ ಎಂದು ಎಂದಿಗೂ ಭಾವಿಸಬೇಡಿ.