---
# System prepended metadata

title: 'Tiny-Poly : L''architecture de l''application'

---


# Tiny-Poly : L'architecture de l'application
>Mahe Thomas | Michel Marmone--Marini | Brandon Fontany--Legal | Aymeric Valdenaire
## Architecture globale

<center>
    <img src="https://i.imgur.com/AJsX3pj.png"/>
</center>

Architecture corrigée, moins complexe et moins coûteuse.

Lorqu'un utilisateur effectue une demande de ptit-u, celui-ci l'obtient immédiatement. Une tâche est alors mise en file d'attente afin d'écrire la redirection dans le système. Un service au sein de l'application est alors chargé de consommer ces tâches.

Lors d'un accès, le service de redirection fait une requête à la base de données afin d'obtenir l'url correspondant au ptit-u et une tâche dans deux files. L'une dédiés à l'écriture du fichier de log et l'autre dédié à l'écriture en base de données les informations d'accès dans la table TinyObjectActivity. 



## Architecture de la couche donnée

<center>
    <img src="https://i.imgur.com/zKyzwp2.png"/>
</center>


---

Nous avons opté pour deux services ayant chacun leur spectre d'utilisation :

* **CloudSQL** pour le stockage des redirections (ptit-url et ptit-image). Notre service proposant des ptit-u disponible pour une durée illimité, il est important de confier ce stockage à un système en accord avec les principes ACID.
La table `PTITURL` contient l'ensemble des informations servant à identifier un ptit-u, elle sera utilisée au sein des instances de notre cluster kubernetes pour récupérer les redirections.
Dans le cadre d'un déploiement à grande échelle de l'application, il nous serait possible de migrer notre base CloudSQL vers le service Cloud Spanner afin de répliquer notre base de données dans plusieurs zones géographiques.

* **Cloud Storage** pour le stockage des images. A l'inverse des redirections les images doivent être stockées pour une durée limitée (5 minutes). Etant donné cette durée de vie faible, aucune réplication de bucket n'est envisagée.



## Estimation du coût

#### Pour 1000 convertions : 

##### Cloud SQL

La tarification Cloud SQL n'étant pas basée sur le nombre de requêtes mais sur les ressources allouées à notre instance, le coût de fonctionnement est donc fixe.

Nous estimons avoir besoins de 10GB de stockage sur une instance `db-f1-micro` disposant de 1GB de backup. 

Coût mensuel : **9,45$**

##### Cloud Storage 

Nous prenons en compte le poids maximal d'une image sans compression (4MB).
Il y a deux facteurs à prendre en compte dans le calcul du coût du stockage : le stockage en lui-même et les opérations (lecture/écriture) effectuées sur les données. Le stockage en lui-même étant une opération et en sachant que les images doivent être supprimées au bout de 5 minutes, le montant relatif aux opérations affiché ci-dessous correspond à ces 2 opérations.

> **1000 Images**
> 
>    Stockage : 0,08$
>    1000 écritures : 0,0051$
>    1000 suppressions : 0,0051$
>    
>    Total : 0,0902$
>