# Title for the RFC

| Author                     | Responsible Squad |
|----------------------------|-------------------|
| Your Name                  | The Squad         |

## Description of your service

Describe in a few words what will your service do.

## How will it be tested?

Will the new microservice be tested both in isolation (with unit tests or mock dependencies)
and in a more realistic “integration” or “staging” environment where it is connected to the same
kinds of services it will touch in production? Will the tests incorporate performance verification
and failure modes?

## How will it be consumed by other parts of the system?

Will those other components interact with the new microservice synchronously or asynchronously?
Should they be encouraged to cache responses from it for some time? What about retries and idempotency?
Will the uptime SLA of the new microservice match that of the other components in the system?

## How will it be secured?

Does your service needs to be secured? Will it use the API Gateway to be secured?

## How will it scale with increasing load?

Will the microservice auto-scale? Is there state held in memory that will make that auto-scaling and
request routing difficult (for example, user session state)? What is the sharding strategy, if any?

## How will it handle failures of its dependencies?

Even microservices built with a very small bounded context might be dependent on other existing
microservices or monoliths present in the system. If your new microservice depends on any other services,
it is crucial to know what should happen when those dependencies fail. Using consistent request timeouts
would be a good start, but adding circuit breaking would be even better.

## How will the rest of the system handle the failure of the new microservice?

Depending on how much investment has been made in the new microservice’s ability to be highly available,
and also depending on what kind of transactions it supports, this might be of minimal concern.

## If your service includes its own data store and a data migration is necessary, how will that be handled?

Depending on the nature of the microservice, it usually includes its own private data store. Often this means data needs to be migrated from an existing legacy database. If that is the case with your service, what is the migration plan and how will you mitigate platform downtime?

## Technical details

| Description                      |                                 |
|----------------------------------|---------------------------------|
| Language                         | `php`, `go`, `python`, `node`   |
| Concourse group                  | `your-service`                  |
| Kubernetes service name          | `your-service`                  |
| Grafana group                    | `your-service`                  |
| Graylog search string            | `your-service`                  |

## Checklist

I have implemented the following prerequsites to my new service:

- [ ] Data Store Replicas
- [ ] CI
- [ ] CD
- [ ] Logging
- [ ] Monitoring
- [ ] Distributed tracing
- [ ] API design (RAML / Swagger / Protobuf, as appropriate)