# Origin Run Book

## Service or system overview

**Service or system name:**
- financial-services-backend

### Technical overview

> What kind of system is this? Web-connected order processing? Back-end batch system? Internal HTTP-based API? ETL control system?

- Internal API based on Python, PostgreSQL and RabbitMQ, deployed in Docker containers on ECS and EC2 instances.
- Webapp that enable users to consume our financial services through advisors and integration with 3rd party services.

### Service Level Agreements (SLAs)

> What explicit or implicit expectations are there from users or clients about the availability of the service or system?

- The service should be available 24/7

### Service owner

> Which team owns and runs this service or system?

- Origin Financial software development team.

### Contributing applications, daemons, services, middleware

> Which distinct software applications, daemons, services, etc. make up the service or system? What external dependencies does it have?

- Python app + PostgreSQL for persistency + RabbitMQ for event dispatching.
- React webapp + REST Api.

### Data and processing flows

> How and where does data flow through the system? What controls or triggers data flows?

- HTTP requests
- Scheduled jobs

### Infrastructure and network design

> What servers, containers, schedulers, devices, vLANs, firewalls, etc. are needed?

- Docker containers running on AWS ECS + 1 AWS Region + 2 AWS Zones + 2 VPCS per Zone + Route53 + S3 Bucket

#### Throttling and partial shutdown - internal components

- Healthcheck endpoint: `/`

### Environmental differences

> What are the main differences between Production/Live and other environments? What kinds of things might therefore not be tested in upstream environments?

- Only the staging and production environments can dispatch SMS messages to the users.

## System configuration

### Configuration management

> How is configuration managed for the system?

- Backend and Frontend:
- Settings file that access injected environment variables for it can access its resources.
- Infrastructure:
- Terraform

### Secrets management

> How are configuration secrets managed?

- Secrets are managed by AWS Secret Manager

## System backup and restore

### Backup requirements

> Which parts of the system need to be backed up?

- Our database is on the regular AWS backup schedule

## Monitoring and alerting

### Log aggregation solution

> What log aggregation & search solution will be used?

- The system is using default AWS logging through the ECS task logs.

## Operational tasks

## Running the app locally

> How the application should be run locally?

- Backend application:
- Requirements:
- Docker and docker-compose
- Add the following line to the end of your /etc/hosts file:
- 127.0.0.1 dev.origin.local
- Steps to run the application:
- docker-compose up --build
- Accessing the API:
- Start sending requests to http://dev.origin.local:8080
- Frontend application
- Requirements:
- NPM and Node
- Steps to run the application:
- npm install
- npm start

### Deployment

> How is the software deployed? How does roll-back happen?

- The software is deployed through a continuous delivery and continuous integration engine called CircleCI.
- We use Github for the repositories and Github triggers CircleCI when it receive a push in the `master` branch.
- When triggered CircleCI will run the application tests and, if all pass, it should deploy to Amazon.
- To deploy the app to the amazon our CircleCI runs the following steps:
- Build the Docker image attaching to it the desired tags.(`docker build -t $tag`)
- Push the Docker image to ECR using the desired tags.(`docker push $account-url/$repo:$tag`)
- Pull the Docker image from ECR and updates the task definition.(`docker pull $account-url/$repo:$tag`)

### Routine and sanity checks

> What kind of checks need to happen on a regular basis?

- Healthcheck on `/` endpoint should be checked by AWS.

### Troubleshooting

> How should troubleshooting happen? What tools are available?

- Sentry and New Relic