Integrate webhook call on user email registration with resilient execution strategy

[lamurian]

User Story

As a platform administrator, I want a webhook service to be triggered whenever a user registers their email address so that downstream systems can react to new registrations without impacting the core authentication workflow.

Description

We plan to call an external webhook service every time a user signs up or registers their email address. The initial design considers performing this webhook call synchronously while still ensuring that any webhook failure does not interrupt or block the existing magic-link sign up / sign in flow.

A note from development indicates that synchronous execution is feasible and safe from a functional perspective but may introduce longer response times. This latency could increase if the webhook service becomes slow or overloaded. Although the user may receive the magic-link email before the signup endpoint returns, degraded webhook performance may eventually affect user experience.

If synchronous processing proves problematic, the implementation can be adjusted to run the webhook execution in a separate goroutine, allowing asynchronous processing without delaying the main sign in process.

Originally posted by @luckyAkbar in #245

Next, about the process execution, I think doing it synchronously and handling any error happen during the webhook service call without causing disruption to the existing sign up / sign in flow using magic link is doable. However, one side note is that the user might have to wait a little longer for response after sign in / sign up since we must wait until this extra process to finish before returning the response. Though the user might already got the email before the response is returned. Nevertheless if in the future this proofed to cause significant delay and harm user experience, I think it can be easily fixed since we can perform the process on separate goroutine from the main sign in process.

Proposed Flow

• Implement webhook call on user email registration.
• Execute the webhook synchronously with proper error handling so signup flow remains unaffected.
• Log webhook failures for monitoring and alerting.
• Measure response time impact under expected load.
• Add configuration flag or internal mechanism to switch to asynchronous execution if synchronous delays become significant.
• Validate user experience during signup under degraded webhook performance scenarios.

Reference

• Developer note on synchronous execution implications and fallback to asynchronous processing.

Notes:

• Consider adding timeout controls to prevent long-running webhook calls from delaying responses.
• Ensure retry logic and idempotency considerations are documented for a future asynchronous model.
• Monitor latency and error rates to guide whether a transition to asynchronous processing becomes necessary.

[lamurian]

This issue is partly addressed in #257. Note to self: I need to update the description, so that the webhook service will use [base]/api/v1/hook. Currently, wehbook URL is constructed from .env variables HOOK_URL and HOOK_SERVICE_OMNICHANNEL_SYNC. After #270 is completed, we need to change the url to call our webhook endpoint.