> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wirekite.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Implementation

> This page provides a more detailed view of the architecture, specifically relating to how will you implement wirekite in your infrastructure. 

## Wirekite Components 

Wirekite has three main database entities -- schema, data and change -- and three components -- Extractor, Mover and Loader. The entities are the objects in the database that wirekite works upon, while components are the operators that work on the entities. 

Lets put these all together and we get a sequence in which all the components work on the entities to ultimately establish a target database which is continuously updated from the source database.   

The **sequence** that is to be followed in a real production infrastructure is as follows.   

### <Icon icon="1" iconType="solid" />	Schema

<CardGroup cols={3}>
  <Card title="Schema Extractor" icon="shapes" iconType="solid" horizontal={false} href="/introduction/implementation">
    Extract the Schema of your source database. One Time.
  </Card>

  <Card title="Schema Mover" icon="arrow-right" iconType="solid" horizontal={false} href="/introduction/implementation">
    Move the Schema from source to target database. One Time.
  </Card>

  <Card title="Schema Loader" icon="upload" iconType="solid" horizontal={false} href="/introduction/implementation">
    Load the schema on the target database. One Time.
  </Card>
</CardGroup>

### <Icon icon="2" iconType="solid" />	Data

<CardGroup cols={3}>
  <Card title="Data Extractor" icon="database" iconType="solid" href="/introduction/implementation">
    Extract the Data of your source database. One Time.
  </Card>

  <Card title="Data Mover" icon="arrow-right" iconType="solid" href="/introduction/implementation">
    Move the Data from source to target database. One Time.
  </Card>

  <Card title="Data Loader" icon="upload" iconType="solid" href="/introduction/implementation">
    Load the data on the target database. One Time.
  </Card>
</CardGroup>

### <Icon icon="3" iconType="solid" />	Change

<CardGroup cols={3}>
  <Card title="Change Extractor" icon="database" iconType="regular" href="/introduction/implementation">
    Extract the Changes from your source database. Continuous.
  </Card>

  <Card title="Change Mover" icon="arrow-right" iconType="solid" href="/introduction/implementation">
    Move the Change files from source to target database. Continuous.
  </Card>

  <Card title="Change Loader" icon="upload" iconType="solid" href="/introduction/implementation">
    Load the changes on the target database. Continuous.
  </Card>
</CardGroup>

## Sequential Steps

The following architectural diagram how data will be migrated to a target database and how a replication pipeline will be established from a source to a target database instance.&#x20;

<Frame caption="Wirekite Implementation and Sequence">
  <img src="https://mintcdn.com/wirekite/aJsSdNvdc_dXUkbK/images/DetailedArchitecture.svg?fit=max&auto=format&n=aJsSdNvdc_dXUkbK&q=85&s=355efc01872a106c969a90ee2b03b764" width="947" height="1872" data-path="images/DetailedArchitecture.svg" />
</Frame>

## Design Points

These are some of the noteworthy points regarding the above diagram.&#x20;

1. Wirekite operates using a replica of the customer-facing database instance. This is so we can avoid taking down the active production database instance, while having a quiesced database instance during the initial data extraction. The details of setting up a replica is database vendor-specific. &#x20;

2. Wirekite components - Extractor, Mover, and Loader - can and should run in parallel. This minimizes the amount of time required to load an initial dump, as well as minimizing storage space needed for in-flight data files as they are fetched by the Extractor and loaded by the Loader. The shorter the initial dump/move/load time the shorter the lag when we switch from initial extraction mode to change data capture mode.

3. The performance characteristics - latency and throughput - of the connectivity between source and target as well as the storage database instances and their hosts should be appropriately scaled to the size and activity of the database.

4. The performance of the change data capture must be more than the rate of overall change events in the source database. For example if you are generating a 1 GB MySQL or MariaDB binlog in 10 seconds, you need to scale your endpoints and networking so that the contents of this binlog are extracted, moved, and loaded in significantly less than 10 seconds. If this is not the case, the target database will lag the source database "forever". Specifically the following equation must hold true.&#x20;

<Note>
  **wirekite\_extraction\_time + wirekite\_ship\_time + wirekite\_load\_time \< source\_database\_change\_generation\_time**
</Note>