Cache services and API keys in memory

Same as we’ve done for templates.

For high volume services this should mean avoiding calls to external
services, either the database or Redis.

TTL is set to 2 seconds, so that’s the maximum time it will take for
revoking an API key or renaming a service to propagate.

Some of the tests created services with the same service ID. This
caused intermittent failures because the cache relies on unique service
IDs (like we have in the real world) to key itself.

app/config.py

@@ -400,7 +400,12 @@ class Test(Development):
     NOTIFY_ENVIRONMENT = 'test'
     TESTING = True
 
-    HIGH_VOLUME_SERVICE = ['941b6f9a-50d7-4742-8d50-f365ca74bf27']
+    HIGH_VOLUME_SERVICE = [
+        '941b6f9a-50d7-4742-8d50-f365ca74bf27',
+        '63f95b86-2d19-4497-b8b2-ccf25457df4e',
+        '7e5950cb-9954-41f5-8376-962b8c8555cf',
+        '10d1b9c9-0072-4fa9-ae1c-595e333841da',
+    ]
 
     CSV_UPLOAD_BUCKET_NAME = 'test-notifications-csv-upload'
     CONTACT_LIST_BUCKET_NAME = 'test-contact-list'

app/serialised_models.py

@@ -126,6 +126,7 @@ class SerialisedService(SerialisedModel):
     }
 
     @classmethod
+    @memory_cache
     def from_id(cls, service_id):
         return cls(cls.get_dict(service_id))
 
@@ -156,6 +157,7 @@ class SerialisedAPIKeyCollection(SerialisedModelCollection):
     model = SerialisedAPIKey
 
     @classmethod
+    @memory_cache
     def from_service_id(cls, service_id):
         keys = [
             {k: getattr(key, k) for k in SerialisedAPIKey.ALLOWED_PROPERTIES}