ಬಳಕೆದಾರರು ಒಂದು ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ. ವಿನಂತಿ (request) ನಿಂತುಹೋಗುತ್ತದೆ. ಹತ್ತು ಸೆಕೆಂಡುಗಳ ಮೌನ. ಅವರು ಫಾಲ್‌ಬ್ಯಾಕ್ (fallback) ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ. ಈಗ ಒಂದೇ ಉದ್ದೇಶಕ್ಕಾಗಿ ಎರಡು ಕೆಲಸಗಳು (jobs) ನಡೆಯುತ್ತಿವೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಸೈಡ್ ಎಫೆಕ್ಟ್ಸ್ (side effects), ಎರಡು ಬಾರಿ ಶುಲ್ಕ ವಿಧಿಸುವುದು ಮತ್ತು ಡೇಟಾ ಗೊಂದಲ ಉಂಟಾಗುತ್ತದೆ, ಇದು ನಿಮ್ಮ ಇಡೀ ದಿನವನ್ನೇ ಹಾಳು ಮಾಡಬಹುದು.

ಇದು ಫ್ರಂಟ್‌ಎಂಡ್ ಬಗ್ ಅಲ್ಲ. React ನಲ್ಲಿ ಬಟನ್ ಡಿಸೇಬಲ್ ಮಾಡುವುದು ಅಥವಾ ಡಿಬೌನ್ಸ್ ಟೈಮರ್ (debounce timer) ಬಳಸುವುದು ನಿಮ್ಮನ್ನು ಉಳಿಸಲಾರದು. ಮೊದಲಿನ ವಿನಂತಿ ಈಗಾಗಲೇ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದೆ (in flight). ನೆಟ್‌ವರ್ಕ್ ಕೇವಲ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (response) ನುಂಗಿಬಿಟ್ಟಿದೆ. ನಿಮ್ಮ ಬ್ಯಾಕ್‌ಎಂಡ್ ಪ್ರತಿಯೊಂದು ಹೊಸ ವಿನಂತಿಯನ್ನು ಹೊಸ ಸೂಚನೆಯಾಗಿ ಪರಿಗಣಿಸಿದರೆ, ರಿಟ್ರೈಗಳು (retries) ಹೊರೆಯಾಗುತ್ತವೆ. ನೀವು ಇದನ್ನು ನಿಮ್ಮ API ವಿನ್ಯಾಸ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾದಲ್ಲಿ ಸರಿಪಡಿಸಬೇಕಾಗುತ್ತದೆ.

ಪರಿಹಾರವು ಒಂದು ಸರಳ ರಚನಾತ್ಮಕ ವಿಭಜನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

Jobs ಮತ್ತು Attempts ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ

ಬಳಕೆದಾರರು ಏನು ಬಯಸುತ್ತಾರೆ ಎಂಬುದರ ಸುಸ್ಥಿರ ದಾಖಲೆಯಾಗಿ 'Job' ಅನ್ನು ಪರಿಗಣಿಸಿ. ಇದು ಮಾಲೀಕರು (owner), ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು (parameters), ಟಾರ್ಗೆಟ್ ಪ್ರೊವೈಡರ್ ಮತ್ತು ನಿಖರವಾದ ಉದ್ದೇಶವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. 'Attempt' ಎಂಬುದು ಆ ಉದ್ದೇಶವನ್ನು ಪೂರೈಸಲು ಮಾಡುವ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಯತ್ನವಾಗಿದೆ.

ಒಂದು ಪ್ರಿಂಟ್ ಶಾಪ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಒಂದು ಫೈಲ್ ನೀಡಿದಾಗ ಅವರು ನಿಮಗೆ ಟಿಕೆಟ್ #45 ನೀಡುತ್ತಾರೆ. ಆ ಟಿಕೆಟ್ವೇ 'Job'. ಶಾಪ್ ಇಂಕ್‌ಜೆಟ್ ಪ್ರಿಂಟರ್ ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅದು ಜಾಮ್ ಆಗುತ್ತದೆ. ಅದು ಮೊದಲನೇ ಪ್ರಯತ್ನ (attempt one). ಅವರು ಫೈಲ್ ಅನ್ನು ಲೇಸರ್ ಪ್ರಿಂಟರ್‌ಗೆ ವರ್ಗಾಯಿಸುತ್ತಾರೆ. ಅದು ಎರಡನೇ ಪ್ರಯತ್ನ (attempt two). ಈ ಪ್ರಕ್ರಿಯೆಯ ಉದ್ದಕ್ಕೂ, ಟಿಕೆಟ್ #45 ಬದಲಾಗುವುದಿಲ್ಲ. ಒಂದು ವೇಳೆ ಶಾಪ್ ಪ್ರತಿಯೊಂದು ಪ್ರಿಂಟರ್‌ಗೆ ಹೊಸ ಟಿಕೆಟ್ ನೀಡಿದ್ದರೆ, ನೀವು ಮೂರು ಬಾರಿ ಹಣ ಪಾವತಿಸಬೇಕಾಗುತ್ತಿತ್ತು ಮತ್ತು ಮೂರು ಅನಗತ್ಯ ಪ್ರತಿಗಳನ್ನು ಪಡೆಯಬೇಕಾಗುತ್ತಿತ್ತು.

ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಕೂಡ ಇದನ್ನೇ ಪ್ರತಿಬಿಂಬಿಸಬೇಕು. ಒಂದು ಟೇಬಲ್ 'Jobs' ಅನ್ನು ಹೊಂದಿರಲಿ. ಇನ್ನೊಂದು ಟೇಬಲ್ 'Attempts' ಅನ್ನು ಹೊಂದಿರಲಿ. 'Job' ಸಾಲು (row) ಸ್ಥಿರವಾಗಿರುತ್ತದೆ, ಆದರೆ ಅದರ ಅಡಿಯಲ್ಲಿ 'Attempts'ಗಳು ಸಂಗ್ರಹವಾಗುತ್ತಾ ಹೋಗುತ್ತವೆ.

ಈ ಪ್ರತ್ಯೇಕತೆಯು ನಿಮಗೆ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ. ನೆಟ್‌ವರ್ಕ್ ಏರುಪೇರುಗಳ ನಡುವೆಯೂ ಉಳಿಯುವ 'idempotency key' ಅನ್ನು ಜೋಡಿಸಲು ಇದು ನಿಮಗೆ ಜಾಗವನ್ನು ನೀಡುತ್ತದೆ.

ಪ್ರತಿ Job ಗೂ Idempotency Key ಅನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ

ಒಂದು Job ಅನ್ನು ರಚಿಸುವ ಪ್ರತಿಯೊಂದು POST ವಿನಂತಿಯು ವಿಶಿಷ್ಟವಾದ 'idempotency key' ಅನ್ನು ಹೊಂದಿರಲೇಬೇಕು. ಈ ಕೀ (key) ಬಳಕೆದಾರರಿಗೆ ಸೇರಿದ್ದೇ ಹೊರತು ಸೆಷನ್‌ಗೆ (session) ಅಲ್ಲ. ಮಾಲೀಕರ ಐಡಿ (owner ID) ಮತ್ತು ಕೀಯನ್ನು ಸಂಯೋಜಿಸಿ, ನಂತರ ಆ ಎರಡು ಕಾಲಂಗಳ ಮೇಲೆ ವಿಶಿಷ್ಟ ಡೇಟಾಬೇಸ್ ನಿರ್ಬಂಧವನ್ನು (unique database constraint) ಜಾರಿಗೊಳಿಸಿ.

ಏಕೆ ಡೇಟಾಬೇಸ್ ನಿರ್ಬಂಧ? ಏಕೆಂದರೆ ಡೇಟಾបញ្ចូលುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸುವುದು 'race condition' ಸಮಸ್ಯೆಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ. ಎರಡು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಗಳು ಒಂದೇ ಮೈಕ್ರೋಸೆಕೆಂಡ್ ಅಂತರದಲ್ಲಿ ಒಳಬರಬಹುದು. ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವ ಸಾಧನವಾಗಿ ಬಳಸಿ. ಬಳಕೆದಾರರು ಒಂದೇ ಮಾಲೀಕ ಐಡಿ ಮತ್ತು ಕೀಯನ್ನು ಎರಡು ಬಾರಿ ಕಳುಹಿಸಿದರೆ, ಎರಡನೇ ವಿನಂತಿಯು ವಿಶಿಷ್ಟ ಉಲ್ಲಂಘನೆಯನ್ನು (unique violation) ಪತ್ತೆಹಚ್ಚುತ್ತದೆ ಮತ್ತು ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ Job ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತೀರಿ. ಎರಡೂ ವಿನಂತಿಗಳಿಗೆ ಒಂದೇ Job ID ಸಿಗುತ್ತದೆ. ಯಾವುದೇ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ.

ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿರಿ. ಯಾರಾದರೂ ಕೀಯನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತಾರೆ ಆದರೆ ಇನ್‌ಪುಟ್ ಪೇಲೋಡ್ (input payload) ಬದಲಾಯಿಸಿದರೆ, 'conflict' ಅನ್ನು ಹಿಂತಿರುಗಿಸಿ. Idempotency key ಕೇವಲ ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರವಲ್ಲದೆ, ನಿಖರವಾದ ಉದ್ದೇಶಕ್ಕೆ (exact intention) ಬದ್ಧವಾಗಿರಬೇಕು. ವಿಭಿನ್ನ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಒಂದೇ ಕೀ ಎಂದರೆ ಕ್ಲೈಂಟ್ ಗೊಂದಲದಲ್ಲಿದ್ದಾನೆ ಎಂದರ್ಥ, ಮತ್ತು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅದನ್ನು ಊಹಿಸುವ ಬದಲು ತಿರಸ್ಕರಿಸಬೇಕು.

State Transitions ಗಳನ್ನು ರಕ್ಷಿಸಿ

ಒಂದು 'Attempt' ಎಂಬುದು ಸ್ಟೇಟ್ ಟ್ರಾನ್ಸಿಶನ್ (state transition), ಹೊಸ Job ಅಲ್ಲ. ಹಿಂದಿನ ಪ್ರಯತ್ನವು ಇನ್ನೂ ಪ್ರಾರಂಭದ ಅಥವಾ ಅಜ್ಞಾತ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದರೆ (starting or unknown state), ನಿಮ್ಮ API ಹೊಸ ಪ್ರಯತ್ನವನ್ನು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ನಿರಾಕರಿಸಬೇಕು.

ಇದಕ್ಕೆ ಕಾರಣಗಳು ಟೈಮೌಟ್‌ಗಳು (timeouts). ಪ್ರೊವೈಡರ್ ವಿನಂತಿ ಟೈಮೌಟ್ ಆದಾಗ, ಕ್ಲೈಂಟ್ ವೈಫಲ್ಯವನ್ನು ನೋಡಬಹುದು, ಆದರೆ ಸರ್ವರ್-ಸೈಡ್ ಪ್ರಕ್ರಿಯೆಯು ಇನ್ನೂ ಜೀವಂತವಾಗಿರಬಹುದು. GPU ಕ್ಲಸ್ಟರ್ ಇನ್ನೂ ನಿಮ್ಮ ಇನ್ಫರೆನ್ಸ್ (inference) ವಿನಂತಿಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿರಬಹುದು. ಕಂಟೇನರ್ ಇನ್ನೂ ಬ್ಲಾಬ್ ಸ್ಟೋರೇಜ್‌ಗೆ ಬರೆಯುತ್ತಿರಬಹುದು. ನೀವು ಟೈಮೌಟ್ ಆದ ಪ್ರಯತ್ನವನ್ನು ವಿಫಲ ಎಂದು ಗುರುತಿಸಿ ತಕ್ಷಣವೇ ಎರಡನೇ ಪ್ರಯತ್ನವನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ನೀವು ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಸೈಡ್ ಎಫೆಕ್ಟ್‌ಗಳ ಅಪಾಯವನ್ನು ಎದುರಿಸುತ್ತೀರಿ.

ಟೈಮೌಟ್ ಅನ್ನು ವಿಫಲ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು ಅಜ್ಞಾತ ಸ್ಥಿತಿ (unknown state) ಎಂದು ಪರಿಗಣಿಸಿ. ಹಿಂದಿನ ಪ್ರಯತ್ನವು ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು (terminal state) ತಲುಪುವವರೆಗೆ ಅಥವಾ ಹೊರಗಿನ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ರದ್ದುಗೊಳಿಸುವವರೆಗೆ ಹೊಸ ಪ್ರಯತ್ನಗಳನ್ನು ತಡೆಯಿರಿ. ಈ ವಿಳಂಬವು ಬಳಕೆದಾರರಿಗೆ ಸ್ವಲ್ಪ ಅಸಮಾಧಾನ ತರಬಹುದು, ಆದರೆ ಇದು ಇಬ್ಬರು ಕೆಲಸಗಾರರು ಒಂದೇ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬದಲಾಯಿಸುವ ಗೊಂದಲವನ್ನು ತಡೆಯುತ್ತದೆ.

Compare-and-Swap ಮೂಲಕ Race ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿ

ಹಲವಾರು ಪ್ರಯತ್ನಗಳು ಪೂರ್ಣಗೊಂಡಾಗ ಅತ್ಯಂತ ಕಠಿಣ ಸಮಸ್ಯೆಗಳು ಎದುರಾಗುತ್ತವೆ. ಬಹುಶಃ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಪ್ರೈಮರಿ ಪ್ರೊವೈಡರ್ ವಿರುದ್ಧ ಮೊದಲ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಿದೆ. ಹತ್ತು ಸೆಕೆಂಡುಗಳ ಮೌನದ ನಂತರ, ಅದು ಫಾಲ್‌ಬ್ಯಾಕ್ ವಿರುದ್ಧ ಎರಡನೇ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಿದೆ. ಈಗ ಎರಡೂ ಪ್ರಯತ್ನಗಳು ಪೂರ್ಣಗೊಂಡಿವೆ. ಎರಡೂ ಪ್ರಯತ್ನಗಳು ತಮ್ಮ ಫಲಿತಾಂಶಗಳನ್ನು ಒಂದೇ Job ಸಾಲಿಗೆ ಬರೆಯಲು ನೀವು ಬಿಡಬಾರದು.

'Compare-and-swap' ತರ್ಕವನ್ನು (logic) ಬಳಸಿ. Job ಸಾಲಿಗೆ ಒಂದು ವರ್ಷನ್ ಸಂಖ್ಯೆಯನ್ನು (version number) ಸೇರಿಸಿ. ಒಂದು ಪ್ರಯತ್ನವು ಪೂರ್ಣಗೊಂಡಾಗ, ಅದು ಈ ಕೆಳಗಿನ ಷರತ್ತುಗಳೊಂದಿಗೆ ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತದೆ:

  • ಪ್ರಸ್ತುತ ವರ್ಷನ್, ಪ್ರಯತ್ನವು ಪ್ರಾರಂಭದಲ್ಲಿ ಓದಿದ ವರ್ಷನ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.
  • ಬೇರೆ ಯಾವುದೇ ಪ್ರಯತ್ನವು ಈಗಾಗಲೇ ಫಲಿತಾಂಶದ ಜಾಗವನ್ನು (result slot) ಪಡೆದುಕೊಂಡಿರಬಾರದು.
  • ಎರಡೂ ಪಾಸಾದರೆ, ಫಲಿತಾಂಶವನ್ನು ಬರೆಯಿರಿ ಮತ್ತು ವರ್ಷನ್ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಿ.

SQL ರೂಪದಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಇದು WHERE id = $1 AND version = $2 AND completed_by IS NULL ಎಂಬ ಕಂಡೀಶನ್‌ನೊಂದಿಗೆ ಅಪ್‌ಡೇಟ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಆಗಿರುತ್ತದೆ. ಅಪ್‌ಡೇಟ್ ಶೂನ್ಯ ಸಾಲುಗಳನ್ನು (zero rows) ನೀಡಿದರೆ, ಇನ್ನೊಂದು ಪ್ರಯತ್ನ ಈಗಾಗಲೇ ಗೆದ್ದಿದೆ ಎಂದರ್ಥ. ತಡವಾಗಿ ಬಂದ ವಿನಂತಿಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಬೇಕು. ಅದರ ಫಲಿತಾಂಶವನ್ನು ಕೈಬಿಡಿ. ಅದನ್ನು ವಿಲೀನಗೊಳಿಸಬೇಡಿ (merge) ಅಥವಾ ಸೇರಿಸಬೇಡಿ (append). ಆ ಕೆಲಸವನ್ನು ಬಿಸಾಡಿಬಿಡಿ. ಮೊದಲಿನ ವಿಜೇತನನ್ನು ಅತಿಯಾಗಿ ಬರೆಯುವ ತಡವಾದ ಫಲಿತಾಂಶವು ಡೇಟಾ ಕೊರಪ್ಷನ್ (data corruption) ಆಗುತ್ತದೆ, ಮತ್ತು ಸುರಕ್ಷಿತ ಕ್ರಮವೆಂದರೆ ಅದನ್ನು ಕೈಬಿಡುವುದು ಮಾತ್ರ.

ಇದು ವಿಲೋಮ ಕ್ರಮದ ಮುಕ್ತಾಯವನ್ನು (reverse-order finish) ಸುಗಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರಯತ್ನ A ಮೊದಲು ಹೊರಡುತ್ತದೆ ಆದರೆ ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮರಳುತ್ತದೆ. ಪ್ರಯತ್ನ B ಎರಡನೆಯದಾಗಿ ಹೊರಡುತ್ತದೆ ಆದರೆ ಐದು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮರಳುತ್ತದೆ. ಪ್ರಯತ್ನ B 'compare-and-swap' ಗೆ ಜಯಗಳಿಸುತ್ತದೆ. ಪ್ರಯತ್ನ A ನ ಅಪ್‌ಡೇಟ್ ಶೂನ್ಯ ಸಾಲುಗಳನ್ನು (zero rows) ಸ್ಪರ್ಶಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಈ ಸ್ಪರ್ಧೆಯನ್ನು (race) ಲಾಗ್ ಮಾಡುತ್ತದೆ, ಹಳೆಯ ಪೇಲೋಡ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದುವರಿಯುತ್ತದೆ.

ಬ್ರೇಕ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ನೀವು 'happy-path' ಪರೀಕ್ಷೆಯಲ್ಲಿ ಈ ಬಗ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಸರಣಿಯು (test suite) ಬಿರುಕುಗಳನ್ನು (fractures) ಗುರಿಯಾಗಿಸಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.

  • ಡಬಲ್-ಕ್ಲಿಕ್ ಅನ್ನು ಅನುಕರಿಸಿ (Simulate). ಒಂದೇ idempotency key ಹೊಂದಿರುವ ಎರಡು ಏಕಕಾಲಿಕ POST ವಿನಂತಿಗಳು (requests) ಒಂದೇ ರೀತಿಯ job IDs ಅನ್ನು ನೀಡಬೇಕು.
  • ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದ ಇನ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಅದೇ ಕೀಯನ್ನು ಕಳುಹಿಸಿ. ಸಂಘರ್ಷದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (conflict response) ನಿರೀಕ್ಷಿಸಿ. ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ, ಸಿಸ್ಟಮ್ ಮೌನವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೆಲಸವನ್ನು (existing job) ಹಿಂತಿರುಗಿಸಬಾರದು.
  • ಟೈಮ್‌ಔಟ್ (timeout) ಉಂಟುಮಾಡಿ. ಕೆಲಸವು 'failed state' ಗೆ ಬಾರದೆ, 'unknown state' ಗೆ ಹೋಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ಅಸ್ಪಷ್ಟತೆ ನಿವಾರಣೆಯಾಗುವವರೆಗೆ ಸಿಸ್ಟಮ್ ಮುಂದಿನ ಪ್ರಯತ್ನಗಳನ್ನು ತಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
  • ಎರಡು ಪ್ರಯತ್ನಗಳು ವಿಲೋಮ ಕ್ರಮದಲ್ಲಿ ಮುಕ್ತಾಯಗೊಳ್ಳುವಂತೆ ಮಾಡಿ. ಮೊದಲನೆಯದು ಹೊರಡಿದ್ದು ಅಧಿಕೃತ ಪ್ರಾಥಮಿಕ ಪೂರೈಕೆದಾರರಾಗಿದ್ದರೂ ಸಹ, ಎರಡನೆಯದಾಗಿ ಮರಳುವ ಪ್ರಯತ್ನ ಸೋಲುತ್ತದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

ಈ ಪರೀಕ್ಷೆಗಳು ಕೇವಲ 'edge-case' ಸೌಲಭ್ಯಗಳಲ್ಲ. ಇವು ನಿಮ್ಮ API ಉಳಿದ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಮಾಡಿಕೊಳ್ಳುವ ಒಪ್ಪಂದಗಳಾಗಿವೆ.

ಫೇಲ್ ಓವರ್ (Fail Over) ಮಾಡುವ ಮೊದಲು ಪೂರೈಕೆದಾರರ ಉದ್ದೇಶವನ್ನು ದೃಢೀಕರಿಸಿ

ನೀವು ಮಲ್ಟಿ-ಪ್ರೊವೈಡರ್ ಸೆಟಪ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ವಿವಿಧ AI ಮಾದರಿಗಳನ್ನು (models) ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಸ್ಲಾಟ್‌ಗಳೆಂದು ಪರಿಗಣಿಸಲು ನೀವು ಪ್ರೇರೇಪಿತರಾಗಬಹುದು. ಅವು ಒಂದೇ ಕೋಡ್ ಪಾತ್, ಒಂದೇ HTTP ಕ್ಲೈಂಟ್ ಮತ್ತು ಒಂದೇ JSON ಸ್ಕೀಮಾವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಆದರೆ ಅವುಗಳ ವರ್ತನೆ ಒಂದೇ ಎಂದರ್ಥವಲ್ಲ.

ಒಂದು ಮಾದರಿಯು ಟಾಪ್-ಲೆವೆಲ್ ಕೀಯನ್ನು ಸೃಷ್ಟಿಸಬಹುದು (hallucinate). ಇನ್ನೊಂದು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ಸ್ಕೀಮಾ ವ್ಯಾಲಿಡೇಶನ್ (Schema validation) ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ವಿಶ್ಲೇಷಿಸಲು ಸಾಧ್ಯವಾಗದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅದು ಅಂಗೀಕರಿಸಬಹುದು. ಪೂರೈಕೆದಾರರು ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್‌ನೊಂದಿಗೆ ತಪ್ಪು ಮಾಡಬಲ್ಲ ಸರಿಯಾದ JSON ಅನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು.

ಸ್ವಯಂಚಾಲಿತ ಮಾದರಿ ಬದಲಾವಣೆಯನ್ನು (automatic model switching) ಅನುಮತಿಸುವ ಮೊದಲು ಪೂರೈಕೆದಾರ-ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿರಿ. ಫಾಲ್‌ಬ್ಯಾಕ್ ಮಾದರಿಯು (fallback model) ಕಡಿಮೆ ತಾಪಮಾನದಲ್ಲಿ (low temperature) ನಿಮ್ಮ ಔಟ್‌ಪುಟ್ ರಚನೆಯನ್ನು ನಿಜವಾಗಿಯೂ ಗೌರವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಆ ಪೂರೈಕೆದಾರರ ಟೋಕನೈಸರ್ (tokenizer) ಮೂಲಕ ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಸರಿಯಾಗಿ ಪ್ರದರ್ಶನಗೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ನೈಜ ಇನ್‌ಪುಟ್‌ಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣ ರೌಂಡ್ ಟ್ರಿಪ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ಫಾಲ್‌ಬ್ಯಾಕ್ ಮಾದರಿಯು ಅದೇ ಕಾರ್ಯಾಚರಣೆಯ ಒಪ್ಪಂದವನ್ನು (operational contract) ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನೀವು ಸಾಬೀತುಪಡಿಸಿದಾಗ ಮಾತ್ರ ಸ್ವಯಂಚಾಲಿತ ಫೇಲ್‌ಓವರ್ ಸುರಕ್ಷಿತವಾಗಿರುತ್ತದೆ.

ಪ್ರತಿ ಉದ್ದೇಶಕ್ಕೆ ಒಂದು ಕೆಲಸವನ್ನು ಮಾತ್ರ ಇರಿಸಿ

ಫಾಲ್‌ಬ್ಯಾಕ್ ಮಾರ್ಗಗಳು ಒಳ್ಳೆಯದು. ಆದರೆ ನಿಯಂತ್ರಣವಿಲ್ಲದ ಫಾಲ್‌ಬ್ಯಾಕ್ ಗುಣಾಕಾರವು (multiplication) ಒಂದು ಬಗ್ ಆಗಿದೆ. ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್‌ನ ಪ್ರತಿಯೊಂದು ಪದರವು ತಾನು ಈಗಾಗಲೇ ನಿಖರವಾದ ಕಾರ್ಯವನ್ನು ನೋಡಿದೆಯೇ ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಲೋಡ್ ಬಾಲನ್ಸರ್, API ಹ್ಯಾಂಡ್ಲರ್, ಡೇಟಾಬೇಸ್ ಮತ್ತು ವರ್ಕರ್ ಎಲ್ಲವೂ ಒಂದೇ ಗುರುತನ್ನು (identity) ಗೌರವಿಸಬೇಕು.

ರಿಟ್ರೈಗಳು (retries) ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು ಒಂದೇ ಸ್ಥಿರ ಕೆಲಸದ ಅಡಿಯಲ್ಲಿ ಹೊಸ ಪ್ರಯತ್ನಗಳಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುವಂತೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಡೇಟಾಬೇಸ್ ಆಧಾರಿತ idempotency key ಮೂಲಕ ಕೆಲಸವನ್ನು ಲಾಕ್ ಮಾಡಿ. ಪರಿವರ್ತನೆಗಳನ್ನು (transitions) ರಕ್ಷಿಸಿ. ಪ್ರಯತ್ನಗಳಿಗೆ ಸ್ಪರ್ಧೆ ನೀಡಿ. ಕೇವಲ ಒಂದೇ ಒಂದು ಗೆಲ್ಲಲಿ. ಹೀಗೆ ಮಾಡುವುದರಿಂದ ಬಳಕೆದಾರರ ಒಂದು ಕ್ಲಿಕ್ ವಾರಾಂತ್ಯದ ಡೇಟಾ ಕ್ಲೀನಪ್ ಕೆಲಸವಾಗಿ ಬದಲಾಗುವುದನ್ನು ನೀವು ತಡೆಯಬಹುದು.