# Functionality

The recurring transfers work by creating some of the jobs needed in the next months, but not all of them. \
This is because the Client needs to know the next 30 days of transfers that will be executed.

Every time a job is executed by the **Jobs Server** or by the **Linker** **API**, it will generate the jobs that needs to be executed in the next 2 months, if there are already created, it will not change anything.

## Main Flow

* Client schedule a recurring transfer with the **Linker API**, if the transfer starts today, it will execute it immediately without passing to the **Jobs Server**, and it will schedule the next recurring transfer jobs that need to be executed, with status of **PENDING**. If it is not today, it will only create the jobs with status of **PENDING.**
* Once the schedule execution day of a job arrives, the **Scheduler Lambda** will take it, change the status to **IN\_FLY**, and send it to the **SQS queue**.
* The **SQS Queue** will send the job in batches to the **Processor Lambda**.
* The **Processor Lambda** will send the jobs to the **Jobs Server**.
* The **Jobs Server** will:
  * &#x20;Change the status of the job to **PROCESSING**
  * Execute the transfer with the **BaaS** provided
  * Change the status of the job to **FINISHED**
  * Schedule the next recurring transfer jobs that need to be executed.\
    \
    If something goes wrong with the **BaaS**, for example it is down, it will change the status of the job to **RETRY** so the **Retries  Lambda** can take it and do all the flow again.
