ಹೊಸ Laravel-ಕೇಂದ್ರಿತ ಮಾರ್ಗದರ್ಶಿಯು, ವೆಬ್‌ಹುಕ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವ ಮೂಲಕ, ಐಡೆಂಪೊಟೆನ್ಸಿ (idempotency) ಗಾಗಿ Redis ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಮತ್ತು ಭಾರೀ ಕೆಲಸಗಳನ್ನು ಕ್ಯೂಗಳಿಗೆ (queues) ವರ್ಗಾಯಿಸುವ ಮೂಲಕ, Telegram ಬಾಟ್‌ಗಳು ಟೈಮ್‌ಔಟ್ ಆಗದಂತೆ, ಕ್ರಿಯೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸದಂತೆ ಅಥವಾ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಕ್ರ್ಯಾಶ್ ಆಗದಂತೆ ಹೇಗೆ ತಡೆಯಬಹುದು ಎಂಬುದನ್ನು ಡೆವಲಪರ್‌ಗಳಿಗೆ ತೋರಿಸಿಕೊಡುತ್ತದೆ.

Telegram ವೆಬ್‌ಹುಕ್‌ಗಳಿಗೆ ಕೇವಲ ಒಂದು ಸರಳ ರೂಟ್ (route) ಮಾತ್ರ ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

Telegram ಪ್ರತಿ ಬಳಕೆದಾರರ ಸಂವಹನವನ್ನು (interaction) ಡೆವಲಪರ್ ಸೂಚಿಸಿದ URL ಗೆ HTTP POST ಮೂಲಕ ಬಾಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಒಳಗೆ 200 OK ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ; ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ ಅದು ವಿನಂತಿಯನ್ನು (request) ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ (retry). ಮರುಪ್ರಯತ್ನಗಳು ಎಂದರೆ ಒಂದೇ update_id ಹಲವು ಬಾರಿ ಬರಬಹುದು, ಮತ್ತು ಬಾಟ್ ವಿನಂತಿಯ ಒಳಗೇ ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯುತ್ತಿದ್ದರೆ ಅಥವಾ ಬಾಹ್ಯ API ಗಳನ್ನು ಕರೆಯುತ್ತಿದ್ದರೆ, ಅದು ಡೂಪ್ಲಿಕೇಟ್ ಸಾಲುಗಳು (duplicate rows), ದ್ವಿಗುಣ ಸಂದೇಶಗಳು ಅಥವಾ ರೇಸ್ ಕಂಡೀಶನ್‌ಗಳನ್ನು (race conditions) ಉಂಟುಮಾಡಬಹುದು. ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಡಜನ್‌ಗಟ್ಟಲೆ ಅಥವಾ ನೂರಾರು ಸಂದೇಶಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಬಾಟ್‌ಗಳಿಗೆ, ಈ ವಿಳಂಬವು (latency) ಶೀಘ್ರದಲ್ಲೇ ಅಡ್ಡಿಯಾಗುತ್ತದೆ.

1. ಸೀಕ್ರೆಟ್ ಹೆಡರ್ ಬಳಸಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಿ

Telegram ಪ್ರತಿ ವೆಬ್‌ಹುಕ್ ಕರಲ್‌ಗೆ X-Telegram-Bot-Api-Secret-Token ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ಟೈಮಿಂಗ್ ಅಟ್ಯಾಕ್‌ಗಳನ್ನು (timing attacks) ತಪ್ಪಿಸಲು PHP ನ hash_equals ಫಂಕ್ಷನ್ ಬಳಸಿ, ಆ ಹೆಡರ್ ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿರುವ ಸೀಕ್ರೆಟ್ ಜೊತೆಗೆ ಹೋಲಿಸಿ—ಮತ್ತು Telegram ಇಂದ ಬರದ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಿ. Laravel ನಲ್ಲಿ, ಕಂಟ್ರೋಲರ್ ಪೇಲೋಡ್ ಅನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲೇ ಪರಿಶೀಲನೆ ನಡೆಯುವಂತೆ ಈ ಚೆಕ್ ಅನ್ನು ಮಿಡ್ಲ್‌ವೇರ್ (middleware) ನಲ್ಲಿ ಇರಿಸಿ.

2. Redis ಬಳಸಿ ಪ್ರತಿ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ (idempotent) ಆಗಿಸಿ

ಪ್ರತಿ ಬರುವ ಪೇಲೋಡ್ ಒಂದು ವಿಶಿಷ್ಟವಾದ update_id ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆ ID ಅನ್ನು NX (set-if-not-exists) ಫ್ಲಾಗ್ ಬಳಸಿ Redis ಗೆ ಬರೆಯಲು ಈ ಮಾರ್ಗದರ್ಶಿಯು ಸೂಚಿಸುತ್ತದೆ. ಈ ಕಾರ್ಯಾಚರಣೆಯು ಮೊದಲ ಬಾರಿಗೆ ಮಾತ್ರ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ; ಮರುಪ್ರಯತ್ನವು ಕೀ (key) ಈಗಾಗಲೇ ಇರುವುದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವೆಬ್‌ಹುಕ್ ತಕ್ಷಣವೇ 200 OK ಅನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು, ಇದು ಅಪ್‌ಡೇಟ್ ನಿರ್ವಹಣೆಯಾಗಿದೆ ಎಂದು Telegram ಗೆ ಸೂಚಿಸುತ್ತದೆ. Redis ಮೆಮೊರಿಯಲ್ಲಿ ಇರುವುದರಿಂದ, ಈ ಪರಿಶೀಲನೆಯು ಯಾವುದೇ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಡೂಪ್ಲಿಕೇಟ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕೀ ಉಳಿಯುತ್ತದೆ.

3. ಭಾರೀ ಕೆಲಸಗಳನ್ನು ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ಜಾಬ್‌ಗಳಿಗೆ (background jobs) ವರ್ಗಾಯಿಸಿ

ವೇಗದ Redis ಪರಿಶೀಲನೆಯಿದ್ದರೂ ಸಹ, ಬಾಟ್‌ನ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್—ಡೇಟಾಬೇಸ್ ಬರವಣಿಗೆಗಳು, ಥರ್ಡ್-ಪಾರ್ಟಿ API ಕರೆಯುವಿಕೆಗಳು, ಸಂದೇಶ ರಚನೆ—ಎಂದಿಗೂ ವೆಬ್‌ಹುಕ್ ವಿನಂತಿಯ ಒಳಗಡೆ ಚಲಾಯಿಸಬಾರದು. ವೆಬ್‌ಹುಕ್ ಪರಿಶೀಲನೆ ಮತ್ತು update_id ಸಂಗ್ರಹವಾದ ತಕ್ಷಣವೇ Laravel ಕ್ಯೂಡ್ ಜಾಬ್ (queued job) ಅನ್ನು ಡಿಸ್ಪ್ಯಾಚ್ ಮಾಡಿ. HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತಕ್ಷಣವೇ ಕಳುಹಿಸಿ, ವರ್ಕರ್ ತನ್ನದೇ ಆದ ವೇಗದಲ್ಲಿ ಕೆಲಸವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬಿಡಿ. ಇದು ಬಾಟ್ ಅನ್ನು Telegram ನ ಪ್ರತಿಕ್ರಿಯೆಯ ಗಡುವಿನೊಳಗೆ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮರುಪ್ರಯತ್ನ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಪ್ರೊಡಕ್ಷನ್-ಗ್ರೇಡ್ (Production-grade) ತಿದ್ದುಪಡಿಗಳು

  • ರೇಟ್ ಲಿಮಿಟ್‌ಗಳನ್ನು (rate limits) ಗೌರವಿಸಿ. ಬಾಟ್ ತನ್ನ ಪ್ರತಿ ಸೆಕೆಂಡಿನ ಮಿತಿಯನ್ನು ಮೀರಿದಾಗ, Telegram Retry-After ಹೆಡರ್‌ನೊಂದಿಗೆ 429 Too Many Requests ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಕ್ಯೂ ವರ್ಕರ್ಸ್ ಆ ಹೆಡರ್ ಅನ್ನು ಓದಬೇಕು ಮತ್ತು ವಿಫಲವಾದ ಜಾಬ್ ಅನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ವಿರಾಮ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.
  • ಪ್ರತಿಕ್ರಿಯಿಸುವ ಮೊದಲು ಡೇಟಾವನ್ನು ಉಳಿಸಿ (Persist). ಯಾವುದೇ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಮೊದಲು ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯಿರಿ; ಯಶಸ್ವಿ ಕಮಿಟ್ ಆದ ನಂತರವಷ್ಟೇ ಬಾಟ್ ದೃಢೀಕರಣ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಬೇಕು. ಈ ಕ್ರಮವು ಸಂದೇಶವು ಬಳಕೆದಾರರಿಗೆ ತಲುಪಿದರೂ, ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ದಾಖಲೆ (record) ಎಂದಿಗೂ ಸೃಷ್ಟಿಯಾಗದಂತಹ ಸಂದರ್ಭಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
  • ಕಾಲಬ್ಯಾಕ್ ಪೇಲೋಡ್‌ಗಳನ್ನು (callback payloads) ಕಡಿತಗೊಳಿಸಿ. Telegram callback_data ಅನ್ನು 64 bytes ಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ಮಿತಿಯೊಳಗೆ ಇರಲು ದೊಡ್ಡ ಬ್ಲಾಬ್‌ಗಳನ್ನು (blobs) ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಬಟನ್ ಪೇಲೋಡ್‌ನಲ್ಲಿ ಕೇವಲ ರೆಫರೆನ್ಸ್ ID ಅನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ.

ಸಾರಾಂಶ: ವಿನಂತಿಯನ್ನು ದೃಢೀಕರಿಸುವುದು (Authenticating), Redis ಬಳಸಿ ಡೂಪ್ಲಿಕೇಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು ಮತ್ತು ಕೆಲಸವನ್ನು ಕ್ಯೂಗಳಿಗೆ ವರ್ಗಾಯಿಸುವುದರಿಂದ, Laravel ಡೆವಲಪರ್‌ಗಳು ತಕ್ಷಣವೇ ಉತ್ತರಿಸುವ, ರೇಟ್ ಲಿಮಿಟ್‌ಗಳೊಳಗೆ ಇರುವ ಮತ್ತು ಬಳಕೆದಾರರ ಬೇಡಿಕೆಯಂತೆ ಸುಲಭವಾಗಿ ಸ್ಕೇಲ್ ಆಗುವ Telegram ಬಾಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.