Refactor Scorer Service into Distinct Service Groups

[nutrina]

Objective:
Enhance our infrastructure's stability and scalability by segmenting the scorer service into distinct service groups. This will allow for more efficient load handling, safer incremental rollouts, and targeted infrastructure improvements.

Details:
To better manage high loads and facilitate safer and incremental infrastructure updates, we aim to segregate the scorer service's functions into specific groups. Each group can then be individually managed during high traffic periods.

Tasks:

• Passport Requests Service: Handle all ceramic cache requests originating from the Passport App.
• Read-Only Public API Service: Manage all registry requests, excluding submit-passport.
• Submit-Passport Requests Service: Exclusively handle /registry/submit-passport requests.
• Internal API Service: Cater to the API requests used by the scorer web app.

Load Balancer Configuration:

• Configure the load balancer to route traffic based on the HTTP request PATH.
• Each service group should inherit the current autoscaling rules. However, consider reducing the minimum number of tasks if necessary.

Implementation Notes:

• No changes are required for the apps or docker images.
• All services will utilize the same docker image. The differentiation will be in the subset of API requests they handle, as determined by the load balancer.

Future Implications:
This restructuring will enable us to address infrastructure challenges for each task group individually, allowing for risk-reduced testing and solution implementation.

[lucianHymer]

Where do we think the cgrants and trusta_labs modules fit into this? Maybe along side the ceramic cache in Passport Requests Service?

[nutrina]

The /registry/submit-passport endpoints get most hits by far in the /registry path ...

[nutrina]

@lucianHymer I would add that to the Internal API Service ...

[nutrina]

Putting this in blocked, I am looking to pair with somebody to help me pull this over the finish line.