വെബ്ഹുക്ക് (webhook) സുരക്ഷിതമാക്കിയും, ഐഡെംപോറ്റൻസിക്ക് (idempotency) വേണ്ടി Redis ഉപയോഗിച്ചും, കഠിനമായ ജോലികൾ ക്യൂകളിലേക്ക് (queues) മാറ്റിയും ടെലിഗ്രാം ബോട്ടുകൾ ടൈം ഔട്ട് ആകാതെയും, ആക്ഷനുകൾ ഡ്യൂപ്ലിക്കേറ്റ് ആകാതെയും, ലോഡ് വരുമ്പോൾ ക്രാഷ് ആകാതെയും എങ്ങനെ സംരക്ഷിക്കാം എന്ന് ഒരു പുതിയ Laravel-കേന്ദ്രീകൃത ഗൈഡ് ഡെവലപ്പർമാരെ കാണിച്ചുതരുന്നു.

ടെലിഗ്രാം വെബ്ഹുക്കുകൾക്ക് (webhooks) ഒരു സാധാരണ റൂട്ടിനേക്കാൾ കൂടുതൽ എന്തുകൊണ്ട് ആവശ്യമാണ്

ഓരോ ഉപയോക്താവിന്റെയും ഇടപെടലുകൾ (interaction) ഡെവലപ്പർ നിശ്ചയിച്ചിട്ടുള്ള ഒരു URL-ലേക്ക് HTTP POST ആയി ടെലിഗ്രാം ബോട്ടിലേക്ക് അയക്കുന്നു. ഏതാനും സെക്കൻഡുകൾക്കുള്ളിൽ പ്ലാറ്റ്‌ഫോം ഒരു 200 OK പ്രതികരണം പ്രതീക്ഷിക്കുന്നു; അതിൽ കൂടുതൽ സമയം എടുത്താൽ അത് ആ റിക്വസ്റ്റ് വീണ്ടും അയക്കും (retry). ഇതിനർത്ഥം ഒരേ update_id തന്നെ പലതവണ ലഭിച്ചേക്കാം എന്നാണ്. റിക്വസ്റ്റിനുള്ളിൽ തന്നെ ബോട്ടുകൾ ഡാറ്റാബേസിലേക്ക് വിവരങ്ങൾ എഴുതുകയോ അല്ലെങ്കിൽ എക്സ്റ്റേണൽ API-കൾ വിളിക്കുകയോ ചെയ്യുന്നുണ്ടെങ്കിൽ, അത് ഡ്യൂപ്ലിക്കേറ്റ് വരികൾ (duplicate rows), ഇരട്ട സന്ദേശങ്ങൾ, അല്ലെങ്കിൽ റേസ് കണ്ടീഷനുകൾ (race conditions) എന്നിവയ്ക്ക് കാരണമായേക്കാം. സെക്കൻഡിൽ ഡസൻ കണക്കിന് അല്ലെങ്കിൽ നൂറുകണക്കിന് സന്ദേശങ്ങൾ കൈകാര്യം ചെയ്യുന്ന ബോട്ടുകളെ സംബന്ധിച്ചിടത്തോളം, ഈ കാലതാമസം (latency) ഒരു വലിയ തടസ്സമായി മാറും.

1. ഒരു സീക്രട്ട് ഹെഡർ ഉപയോഗിച്ച് എൻഡ്പോയിന്റ് സുരക്ഷിതമാക്കുക

ഓരോ വെബ്ഹുക്ക് കോളിലും ടെലിഗ്രാം ഒരു X-Telegram-Bot-Api-Secret-Token ഹെഡർ ചേർക്കുന്നു. ടൈമിംഗ് അറ്റാക്കുകൾ (timing attacks) ഒഴിവാക്കാൻ PHP-യുടെ hash_equals ഫംഗ്ഷൻ ഉപയോഗിച്ച്, ആ ഹെഡറിനെ സെർവറിൽ സൂക്ഷിച്ചിരിക്കുന്ന ഒരു സീക്രട്ടുമായി താരതമ്യം ചെയ്യുക—ടെലിഗ്രാമിൽ നിന്ന് അല്ലാത്ത ഏത് റിക്വസ്റ്റും നിരസിക്കുക. Laravel-ൽ, ഈ പരിശോധന ഒരു middleware-ൽ ഉൾപ്പെടുത്തുക, അങ്ങനെ കൺട്രോളർ (controller) പേലോഡ് (payload) കൈകാര്യം ചെയ്യുന്നതിന് മുമ്പ് തന്നെ വെരിഫിക്കേഷൻ നടക്കുന്നു എന്ന് ഉറപ്പാക്കാം.

2. Redis ഉപയോഗിച്ച് ഓരോ അപ്ഡേറ്റും ഐഡെംപോറ്റന്റ് (idempotent) ആക്കുക

വരുന്ന ഓരോ പേലോഡിലും ഒരു തനതായ update_id ഉണ്ടായിരിക്കും. ആ ID NX (set-if-not-exists) ഫ്ലാഗ് ഉപയോഗിച്ച് Redis-ൽ രേഖപ്പെടുത്താൻ ഈ ഗൈഡ് നിർദ്ദേശിക്കുന്നു. ആദ്യത്തെ തവണ മാത്രമേ ഈ ഓപ്പറേഷൻ വിജയിക്കുകയുള്ളൂ; ഒരു റിട്രൈ (retry) വരുമ്പോൾ ആ കീ അവിടെ നിലവിലുണ്ടെന്ന് കണ്ടെത്തുന്നതോടെ വെബ്ഹുക്കിന് ഉടൻ തന്നെ 200 OK തിരികെ നൽകാം. ഇത് അപ്ഡേറ്റ് കൈകാര്യം ചെയ്തതായി ടെലിഗ്രാമിനെ അറിയിക്കുന്നു. Redis മെമ്മറിയിൽ പ്രവർത്തിക്കുന്നതിനാൽ, ഈ പരിശോധന കാലതാമസം ഉണ്ടാക്കുന്നില്ല, കൂടാതെ ഡ്യൂപ്ലിക്കേറ്റുകൾ കണ്ടെത്താൻ ആ കീ അവിടെത്തന്നെ നിലനിൽക്കുകയും ചെയ്യുന്നു.

3. കഠിനമായ ജോലികൾ ബാക്ക്ഗ്രൗണ്ട് ജോബുകളിലേക്ക് മാറ്റുക

വേഗതയേറിയ Redis പരിശോധന ഉണ്ടെങ്കിൽ പോലും, ബോട്ടുകളുടെ ബിസിനസ് ലോജിക്—ഡാറ്റാബേസ് എഴുത്തുകൾ, തേർഡ് പാർട്ടി API കോളുകൾ, സന്ദേശങ്ങൾ തയ്യാറാക്കൽ എന്നിവ—ഒരിക്കലും വെബ്ഹുക്ക് റിക്വസ്റ്റിനുള്ളിൽ തന്നെ പ്രവർത്തിപ്പിക്കരുത്. വെബ്ഹുക്ക് വെരിഫൈ ചെയ്യുകയും update_id സ്റ്റോർ ചെയ്യുകയും ചെയ്താലുടൻ ഒരു Laravel queued job ഡിസ്പാച്ച് ചെയ്യുക. HTTP റെസ്പോൺസ് ഉടൻ തന്നെ അയച്ചു കൊടുക്കുക, അങ്ങനെ വർക്കർ (worker) അതിന്റെ വേഗതയിൽ ജോലി പൂർത്തിയാക്കാൻ അനുവദിക്കുക. ഇത് ബോട്ടുകളെ ടെലിഗ്രാമിന്റെ റെസ്പോൺസ് ഡെഡ്‌ലൈനുള്ളിൽ നിലനിർത്തുകയും പ്ലാറ്റ്‌ഫോം റിട്രൈ ചെയ്യുന്നത് തടയുകയും ചെയ്യുന്നു.

പ്രൊഡക്ഷൻ നിലവാരത്തിലുള്ള മാറ്റങ്ങൾ (Production-grade tweaks)

  • റേറ്റ് ലിമിറ്റുകൾ (rate limits) പാലിക്കുക. ഒരു ബോട്ടിൽ സെക്കൻഡിൽ അനുവദനീയമായ പരിധി കഴിഞ്ഞാൽ, ടെലിഗ്രാം Retry-After ഹെഡറിനൊപ്പം 429 Too Many Requests എന്ന എറർ നൽകുന്നു. ക്യൂ വർക്കറുകൾ ആ ഹെഡർ വായിക്കുകയും പരാജയപ്പെട്ട ജോലി വീണ്ടും ചെയ്യാൻ ശ്രമിക്കുന്നതിന് മുമ്പ് അൽപ്പനേരം നിർത്തിവെക്കുകയും വേണം.
  • മറുപടി നൽകുന്നതിന് മുമ്പ് വിവരങ്ങൾ സേവ് ചെയ്യുക. ഉപയോക്താവിന്റെ ഏതെങ്കിലും ഡാറ്റ ആദ്യം ഡാറ്റാബേസിൽ രേഖപ്പെടുത്തുക; ഡാറ്റാബേസ് കമ്മිට് (commit) വിജയകരമായി പൂർത്തിയായതിന് ശേഷം മാത്രമേ ബോട്ടുകൾ സ്ഥിരീകരണ സന്ദേശം അയക്കാവൂ. ഇത് സന്ദേശം ഉപയോക്താവിന് ലഭിക്കുകയും എന്നാൽ അതിന് അനുബന്ധമായ റെക്കോർഡ് ഡാറ്റാബേസിൽ ഇല്ലാതിരിക്കുകയും ചെയ്യുന്ന സാഹചര്യം ഒഴിവാക്കുന്നു.
  • callback payloads കുറയ്ക്കുക. ടെലിഗ്രാമിൽ callback_data-യുടെ പരിധി 64 bytes ആണ്. വലിയ ഡാറ്റകൾ ഡാറ്റാബേസിൽ സൂക്ഷിക്കുകയും, ബട്ടൺ പേലോഡിൽ ഒരു റഫറൻസ് ID മാത്രം നൽകുകയും ചെയ്യുന്നതിലൂടെ ഈ പരിധിക്കുള്ളിൽ നിൽക്കാം.

ചുരുക്കത്തിൽ: റിക്വസ്റ്റ് ഓതന്റിക്കേറ്റ് ചെയ്യുക, Redis ഉപയോഗിച്ച് ഡ്യൂപ്ലിക്കേറ്റുകൾ ഒഴിവാക്കുക, ജോലികൾ ക്യൂകളിലേക്ക് മാറ്റുക എന്നിവയിലൂടെ, ഉടൻ തന്നെ മറുപടി നൽകാനും, റേറ്റ് ലിമിറ്റുകൾ പാലിക്കാനും, ഉപയോക്താക്കളുടെ എണ്ണം കൂടുമ്പോൾ സുഗമമായി പ്രവർത്തിക്കാനും (scale) കഴിയുന്ന ടെലിഗ്രാം ബോട്ടുകൾ നിർമ്മിക്കാൻ Laravel ഡെവലപ്പർമാരെ ഇത് സഹായിക്കുന്നു.