Le système de conception d’Uber est un sujet fascinant. Permettez-moi de vous expliquer brièvement comment Uber fonctionne et comment il a évolué au fil du temps.
- Architecture initiale :
- À ses débuts, Uber utilisait une architecture monolithique. Ils avaient un service backend, un service frontend et une seule base de données. Cela fonctionnait bien pour un petit nombre de trajets dans quelques villes.
- Cependant, lorsque le service a commencé à s’étendre à d’autres villes, l’équipe Uber a rencontré des problèmes avec cette architecture.
- Passage à l’architecture orientée services :
- Après 2014, Uber a décidé de passer à une architecture orientée services. Ils ont également étendu leurs services pour inclure la livraison de nourriture et le transport de marchandises.
- L’architecture d’Uber repose désormais sur des microservices.
- L’un des principaux défis d’Uber est de mettre en relation les passagers avec les chauffeurs. Pour cela, ils ont deux services distincts :
- Service d’approvisionnement (pour les chauffeurs)
- Service de demande (pour les passagers)
- Uber utilise un système de dispatch (optimisation de la répartition) pour mettre en correspondance l’offre et la demande. Ce système utilise des téléphones mobiles et est responsable de la mise en relation des chauffeurs avec les passagers.
- Fonctionnalités clés :
- Exigences fonctionnelles :
- Les utilisateurs doivent pouvoir voir tous les taxis disponibles avec le prix minimum et le temps d’arrivée estimé (ETA).
- Ils doivent pouvoir réserver un taxi pour leur destination.
- Voir la position du chauffeur.
- Annuler leur trajet à tout moment.
- Exigences non fonctionnelles :
- Haute disponibilité.
- Fiabilité élevée.
- Grande évolutivité.
- Faible latence.
- Exigences fonctionnelles :
- Estimation des capacités :
- Supposons que nous ayons 5 millions d’utilisateurs actifs sur l’application Uber, avec 200 000 chauffeurs et en moyenne 1 million de trajets par jour.
- Si un utilisateur effectue en moyenne 5 actions, nous devons gérer environ 5 millions de requêtes par jour.
- En termes de stockage, supposons que chaque message ait une taille moyenne d’environ 500 octets, ce qui nécessiterait environ 2,32 Go d’espace par jour.