J’ai parcouru aujourd’hui la structure du flux de ticker de GRVT, principalement parce que comprendre ce que contient réellement une seule mise à jour de ticker est important pour finaliser l’image des données de marché que je construis tout au long de ce sprint.
Un ticker donne probablement le dernier prix négocié, le plus haut et le plus bas sur 24 heures, le volume sur 24 heures, et sans doute la variation en pourcentage sur la même période, mis à jour sous forme d’un instantané compact plutôt que d’exiger qu’un client calcule lui-même ces statistiques à partir de l’historique brut des transactions.
Ce que je trouve notable, c’est que c’est fondamentalement une couche de commodité placée au-dessus de données qui, techniquement, peuvent être dérivées du flux des transactions que j’ai consulté précédemment. Un client pourrait en théorie calculer le plus haut, le plus bas et le volume sur 24 heures en traitant l’historique complet des transactions, mais le fait que GRVT calcule et diffuse directement ce récapitulatif supprime une charge de calcul réelle pour chacun des clients qui devrait autrement maintenir le même calcul glissant de manière indépendante.
Cela rejoint un schéma que j’ai remarqué cette semaine dans la conception plus globale du flux de GRVT : des données brutes et granulaires existent (profondeur du carnet d’ordres, transactions individuelles), mais des vues résumées, pré-calculées, existent aussi en parallèle, pour les cas où le détail complet n’est pas nécessaire.
Je termine ce sprint avec l’observation que la surface d’API de GRVT semble être conçue de manière cohérente autour de cette même compensation : des données granulaires pour ceux qui ont besoin de précision, et des données résumées pour ceux qui ont seulement besoin d’avoir rapidement une image fiable.
@grvt_io #grvt
Un ticker donne probablement le dernier prix négocié, le plus haut et le plus bas sur 24 heures, le volume sur 24 heures, et sans doute la variation en pourcentage sur la même période, mis à jour sous forme d’un instantané compact plutôt que d’exiger qu’un client calcule lui-même ces statistiques à partir de l’historique brut des transactions.
Ce que je trouve notable, c’est que c’est fondamentalement une couche de commodité placée au-dessus de données qui, techniquement, peuvent être dérivées du flux des transactions que j’ai consulté précédemment. Un client pourrait en théorie calculer le plus haut, le plus bas et le volume sur 24 heures en traitant l’historique complet des transactions, mais le fait que GRVT calcule et diffuse directement ce récapitulatif supprime une charge de calcul réelle pour chacun des clients qui devrait autrement maintenir le même calcul glissant de manière indépendante.
Cela rejoint un schéma que j’ai remarqué cette semaine dans la conception plus globale du flux de GRVT : des données brutes et granulaires existent (profondeur du carnet d’ordres, transactions individuelles), mais des vues résumées, pré-calculées, existent aussi en parallèle, pour les cas où le détail complet n’est pas nécessaire.
Je termine ce sprint avec l’observation que la surface d’API de GRVT semble être conçue de manière cohérente autour de cette même compensation : des données granulaires pour ceux qui ont besoin de précision, et des données résumées pour ceux qui ont seulement besoin d’avoir rapidement une image fiable.
@grvt_io #grvt