Dev NodeJs serveur RestFull stockage in memory

Dans le cadre de l’amélioration de modules d’une Startup dans le milieu des télecoms et de la publicité, nous recherchons un développeur en mesure de développer en NodeJs un serveur RESTFULL répondant à deux primitives :
- Une primitive de stockage mémoire non persistant de tickets
- Une primitive d’interrogation de seuils

Primitive de stockage
Chaque ticket à stocker est sous la forme Client, Campaign, TimeStamp ou Client et Campaign sont des int.

Primitive d’interrogation
Une primitive d’interrogation pour savoir si on peut servir une campagne pour un client donné en fonction de deux maximums envoyés :
- Un maximum global par Subscriber (2iem champs)
- Un maximum pour un couple Client/Campagne (Ce maximum peut être déterminé sur 3 périodes, il y a donc ajout d’un type de période prenant 3 valeurs possibles (1= 1 heure glissante,2=12 heures glissantes, 3=24 heures glissante).

L’interface d’appel de l’interrogation est donc :
Subscriber/MaxSubscriber/Campaign/TypePeriod/MaxPeriod.
Exemple: {« Subscriber » : « 876243 », « MaxSub»:« 120 », « Campaign » :« 876 », « TypeP ”:”2”,”MaxPeriod”:”60”}

La réponse attendue est sous la forme d’un champ unique : GlobalRespons
Respons Explanation :
- 0 (Serve this campaign for this client)
- 1 (Don’t serve this client Global maximum per Client reach)
- 11 (Don’t serve this campaign for this client Reason Maximum campaign hour reach)
- 12 (Don’t serve this campaign for this client Reason Maximum campaign for 12 hours reach)
- 13 (Don’t serve this campaign for this client Reason maximum campaign for 24 hours reach)

Les appels au serveur doivent être en RESTFULL, les paramètres en POST au format JSON, l’authentification de type Basic avec login/mot de passe.

Le serveur à développer peut-être appelé par plusieurs client RESTFULL simultanément (prévu de 1 à 4 clients Nodejs maximum).
Toutefois le subscriber final ne peut pas appeler la plateforme plusieurs fois simultanément, il n’y a pas de comptage bloquant à gérer par subscriber ou scubscriber/campaign).

Aucune constante ne doit être présente dans le code, les variables seront toutes chargées au démarrage du serveur. Utilisation de l’environnement Pm2 et du fichier ecosystem.config.js
La somme globale des tickets à manager dans le tableau (24h glissant) est d’environ 60 millions.

Les livrables attendus :
- Code documenté du serveur du serveur Nodejs répondant aux deux primitives
- Un code d’exemple de chargement de 60 millions d’entées sur la base de subscribers tirés au hasard parmi une base de 5 millions et disposant en moyenne de 5 à 10 campagnes
- Un code d’exemple de l’appel d’interrogation, affichant le temps de réponse de la recherche.
- Un exemple de code d’appel (Restfull client) à intégrer dans un code NodeJs déjà existant plus global. (Code d’appel du stockage, Code d’appel de l’interrogation). Ces deux appels devant être bloquant au maximum pendant 50ms et ne plus attendre au-delà (Serveur hs ou ne répondant pas dans les temps définis).

Dans cette version, les données ne doivent pas être persistante au-delà du process nodejs sur le serveur.

Autrement dit, au démarrage, le tableau interne est vide, et évolue au fur et à mesure des requêtes de stockage.
La période de recherche temporelle la plus grande étant de 24h, le tableau doit « oublier » progressivement les tickets dont le timestamp est >24h.
Le choix du fournisseur sera réalisé sur la base de :
- L’empreinte mémoire proposé et nécessaire au stockage du tableau et des cumuls
- Des performances de recherche (Seuil de 20ms pour le stockage et 50 ms pour la recherche dans un tableau de 60 millions d’entrées une fenêtre de 24h glissante).
Les temps de réponse souhaités sont envisagés sur un serveur de type Intel E5 ou Xeon sous linux disposant de 60% de la CPU et de 64Gb de RAM.

Nous sommes ouverts a toute technologie de stockage InMemory Open source, ayant fait ses preuves, disposant d’une communauté de développement significative et pouvant évoluer vers du stockage persistant pour une prochaine release.

Cette demande est dans le cadre d’autres tâches ultérieures faisant partie d’un plan produit global d’environ 30 à 50 jours en 2019 dans cette technologie (NodeJs).

Le développement est à livré pour le 15/01/2019