API Gateway Design Ideation

Overview

• We have a need to aggregate the APIs exposed by a number of different microservices. Each of these microservices will likely be running in its own Docker container and there may be multiple instances of a single microservice for  scalability or redundancy. The APIs are all REST-based APIs with JSON or GraphQL payloads.
• The APIs need to be aggregated in a single place both for invocation and documentation. The documentation standard we use is OpenAPI.
• The purpose of this challenge is for you to provide us with a number of possible options (ideas) for how we might achieve our goal. The provided options should consider industry best practices, the known results of other API aggregation projects and any frameworks that already exist for this purpose. The options must all abide by the constraints listed below. 

Constraints

• All options must support aggregation of the APIs of microservices running in different containers
• All options must allow the creation of a unique request ID that can be propagated through all downstream calls to facilitate tracing
• All options must be able to forward authentication tokens and handle redirection if “unauthorized” responses come back from downstream services
• All options must be compatible with Kubernetes
• Aggregation must support JSON REST APIs and GraphQL
• API documentation aggregation must support the OpenAPI format
• Any additional components introduced must be scalable and not introduce a single point of failure
• Any frameworks or supporting technologies proposed in an option must be free open source and available under an MIT (or equivalent) licence.

  
Expected Results
Options for aggregating the APIs of multiple microservices into a single API.
 
For each option, please provide the following:

• Description of the aggregation approach 
• Benefits and drawbacks of the approach, including how / if it handles the following areas:
  • Routing of calls
  • Aggregation of APIs
  • Aggregation of API documentation
  • Scalability
  • Logging
  • Monitoring
  • Transformation of requests and responses)
  • Filtering of request
  • Circuit Breaker pattern
  • Billing / Metering of calls
  • Extensibility
  • Authorization
• A list of frameworks or supporting technologies required to use the approach
• Links to any public references (blog posts etc.) that document successful implementations of the approach at other organisations

 
Checkpoint

• Checkpoint submissions are accepted before 11/12/2019 at 12:00 EST, and we'll pick the top 2 checkpoint winners which would each receive an additional bonus of $100.
• You must also submit to the final round and pass review to receive the checkpoint bonus.

Review
The review of this challenge will be subjective and winners will be picked by the client.

Final Submission Guidelines

• A single zip file containing your submission that covers all the constraints.