I’m in the process of redesigning a ServiceStack-based API and web app to solve a response-time problem with requests from Twilio.
Right now the app is hosted on Azure with SQL Server persistence and a Redis cache. However, very frequently (once a week) Azure has some sort of slowdown or issue accessing the SQL Server, and requests exceed Twilio’s 15-second timeout. Right now we are pushing these timed-out requests to a second instance of the app (including SQL and Redis), but that “solution” creates replication and synchronization complexity that we want to avoid.
Twilio supports request authentication to guarantee that a request is coming from their servers. Given that, I’m looking to simplify this part of the application by skipping the ServiceStack authentication process, but only for this part of the app. The publicly-accessible web UI and web API still require authentication. My desire is to have this part of the app be able to quickly access cached data for the Twilio interaction, then publish a command to a service bus that will be picked up for writes to the DB.
Is this sort of design supported in ServiceStack? Or would this be using the framework in a way that wasn’t intended? My alternative is to have that portion of the app be non-ServiceStack and manage caching on my own.