Performance Optimizations

1. Move Zipwhip Send Webhook Processing to a Queue - Because of migrations, we have had to subscribe to what are called "Send Webhooks" which means we get notified every time a message is sent by a client on the Zipwhip network. This was to account for people who were still bouncing between the old portal and our platform. The problem is that it causes a number of issues in our platform. While in the long term we will not be using these webhooks, we have updated how we process them to move them to a queue to handle the load and speed at which they come in.

2. Remove Duplicate Retry Logic on Incoming Message Status Processing - On Zipwhip message status updates we had some additional retry logic that was a carry over from v1 code. When we would get statuses on messages we didn't have in our system (like from our migration customers still using the portal or our legacy Blast) then we would retry the processing more times than needed. We stripped out the duplicate logic so we now do our standard retry of 3 times.