### CSC409 Report (weight 25%): 0/27

### Discussing the system's architecture

#### 0/3 Diagram showing
[0] 1 Application system
[0] 1 Monitoring system
[0] 1 Data flow

#### 0/14 Discussion of each of the following with respect to your system.
For each point, as appropriate, show an appropriate diagram,
list performance guarantees, discuss code/architecture choices.

Example:

Availability:
- the availability guarantees your system provides
- the architectural choices made to implement this

Data Partitioning:
- diagram explaining how data is partitioned
- outline how your code implements this, for example,
if you hash, then which hash algorithm

[0] 1 Consistensy (not implemented)

- more in Data partitioning section.
[0] 1 Availablity (not implemented)
- Each piece of data will be stored in (int(n * 1/3) + 1) different systems,
if less or equal to 1/3 server is down, the data will still be availble.
[0] 1 Partition tolarance (not implemented)
[0] 1 Data paritioning (not implemented)
- Using hash function to partition data
- Let h(data1) = i; System count = n, data1 will store in system i%n (i+1)%n
[0] 1 Data replication (not implemented)
- Mentioned in Data paritioning section, data will be stored in 3 different system.
- As long as one of the three host storing data is up, the data will be fine.
- For example if we have 3 servers, when PUT is hashed to server i, send data to i and i+1. When GET, GET from first, if no request get from the second.
- In general if we have n servers, PUT data to at least (n//3)*2 servers (or ceiling division..).

[0] 1 Load balancing (not implemented)
[0] 1 Caching (not implemented)
[0] 1 Process disaster recovery (not implemented)
[0] 1 Data disaster recovery (not implemented)
[0] 1 Orchestration (not implemented)
[0] 1 Healthcheck (not implemented)
[0] 1 Horizontal scalability (not implemented)
- Very easily add/remove nodes
- dedicate script for this task
- redistribute data after add/remove node.
[0] 1 Vertical scalability (not implemented)
[0] 1 Well formatted document (implemented)
- Perfect document by Zixi Qu

#### 0/4 Discussing the system's performance
[0] 1 Graph showing performance of system under load1
[0] 1 Analysis of system performance under load1
[0] 1 Graph showing performance of system under load2
[0] 1 Analysis of system performance under load2

#### 0/4 Discussing the system's scalability
[0] 1 Number of hosts vs read requests per second
[0] 1 Number of hosts vs write requests per second
[0] 1 Number of hosts vs data stored

#### 0/2 Discussion of the tools used during testing. Listing them is not enough. You must define each tool used, and how you used it

#### Demo (weight 45%): /29

0/7 Functionality
0/3 Long to Short (PUT)
[0] 1 Good request. 201
[0] 1 Bad request. 400
[0] 1 UI shows success or failure messages
0/3 Short to Long (GET)
[0] 1 Good request. 307
[0] 1 Bad request. 404
[0] 1 UI shows success or failure messages
0/1 UI design
[0] 1 Simple and clean user interface

0/5 Monitoring
[0] 1 Monitoring system watching the health of the application system
[0] 1 Monitoring system is fault tolerant
[0] 1 UI showing the status of the hosts
[0] 1 UI shows up to date status
[0] 1 Simple and clean user interface

0/7 Disaster recovery
0/1 Load balancer recovery
[0] 1 Load balancer recovers/heals from a process dying

0/2 Application server recovery
[0] 1 Url shortner recovers/heals from a process dying
[0] 1 Url shortner recovers/heals from a host dying

0/4 Data recovery
[0] 1 Data is persistent after the system recovers/heals from a process dying
[0] 1 Data is persistent after the system recovers/heals from a host dying
[0] 1 The application responds after a database file gets corrupt
[0] 1 The application responds after a database file gets deleted

0/6 Scalability
[0] 1 System can be run from empty with n nodes

                [0] 1 System scales from n to n+1 nodes with minimal intervention

[0] 1 System scales from n to n+1 nodes without downtime
[0] 1 System makes good use of additional compute
[0] 1 System makes good use of additional storage
[0] 1 System makes good use of additional ram

0/4 Orchestration
one bash file for all, command line input:
start/add hostname (call wake function, write hostname to hosts file)
remove hostname (call remove function)
shutdown all (call remove on each host)

[0] 1 Automate launching the cluster onto the given systems
# Similar to lab, read hosts file, wake each host
[0] 1 Automate adding a host to the cluster
# e.g. add a new host in the file, host will start automatically
[0] 1 Automate removing a host from the cluster
# similar kill all java
[0] 1 Automate shutdowning the cluster
# similar