Le poste associe Scala et le modèle acteur. Le développeur écrit des acteurs typés qui échangent des messages, des flux Akka Streams qui consomment Kafka avec contre-pression, des entités réparties par Cluster Sharding et persistées en event sourcing dans Cassandra ou PostgreSQL. La couche web passe par Play Framework ou par Akka HTTP, devenu Pekko HTTP de l'autre côté du fork. Ces systèmes distribués tournent souvent depuis plusieurs années.
Akka classique, avec des acteurs non typés et des ask partout, reste ce que beaucoup de candidats ont appris. Ils connaissent l'envoi de messages, beaucoup moins la supervision, le comportement d'un cluster coupé en deux ou l'évolution d'un événement déjà écrit dans le journal. Demandez ce que deviennent les entités d'un nœud qui disparaît, ou comment on ajoute un champ à un événement persisté : la réponse montre si la personne a déjà exploité un cluster.
Akka et Pekko ne recouvrent pas tout à fait la même chose sur un CV. La migration vers Pekko change les packages, la configuration (akka.* devient pekko.*) et les ports par défaut, et Pekko sait relire les données persistées par Akka. Play 2.9 tourne sur Akka, Play 3 sur Pekko. Le PDF propose un cas de 20 minutes sur le suivi en temps réel d'une flotte de véhicules.
Acteurs, streams, cluster : les briques d'un système Akka ou Pekko
Acteurs typés (Akka Typed, Pekko Typed)
Un acteur traite ses messages un par un et garde un état privé, sans verrou. L'API typée, recommandée depuis Akka 2.6, fixe à la compilation les messages qu'un acteur accepte (Behavior[T]). L'API classique non typée reste présente dans beaucoup de bases de code.
Supervision
Un acteur parent décide du sort d'un enfant en échec : arrêt, redémarrage, reprise, avec un délai croissant si besoin. C'est le mécanisme qui isole les pannes, à condition d'avoir prévu l'état perdu au redémarrage.
Akka Streams, Pekko Streams
Une bibliothèque de flux avec contre-pression, composée d'une source, d'étapes de transformation et d'un puits. Un consommateur lent ralentit automatiquement le producteur. Les connecteurs, Alpakka côté Akka et Pekko Connectors côté Pekko, relient ces flux à Kafka, à S3, à des fichiers ou à des bases.
Cluster et Cluster Sharding
Le cluster réunit plusieurs JVM en un seul système d'acteurs. Cluster Sharding répartit des entités (un compte, un appareil, une session) sur les nœuds selon leur identifiant, et les déplace quand un nœud s'en va. Le Split Brain Resolver décide quel côté survit quand le réseau coupe le cluster en deux, et sa configuration mérite une question à elle seule.
Persistence et event sourcing
Une entité persistante enregistre des événements dans un journal (Cassandra, JDBC, R2DBC, DynamoDB) et retrouve son état en les rejouant, avec des snapshots pour aller plus vite. Les projections lisent ces événements pour alimenter des vues de lecture. Le format des événements est un contrat, à faire évoluer avec soin.
Play Framework
Le framework web pour Scala et Java : routes, contrôleurs asynchrones, Play JSON. Play 2.9 repose sur Akka, Play 3.0 sur Pekko, avec la même API. Il sert souvent d'API REST devant les acteurs.
Akka HTTP, Pekko HTTP
Une alternative plus légère à Play, construite sur les streams, avec un DSL de routes. Elle sert aussi de client HTTP et de base au gRPC (Akka gRPC, Pekko gRPC).
Licence Akka et Apache Pekko
Depuis la version 2.7, sortie en 2022, Akka est publié sous Business Source License : usage libre en développement, licence commerciale de Lightbend pour la production sauf exceptions, passage sous Apache 2.0 trois ans après chaque version. Apache Pekko est le fork d'Akka 2.6 sous licence Apache. Ce choix pèse sur le budget du projet et sur la feuille de route technique.
Ces systèmes ont souvent plusieurs années. Le développeur reprend des acteurs écrits par d'autres, parfois avec l'API classique, et les fait évoluer sans casser les événements déjà persistés ni le cluster en production. Une partie des missions porte sur la migration d'Akka vers Pekko, de Play 2.9 vers Play 3 ou de Scala 2.13 vers Scala 3. Sur un système neuf, il faut au contraire décider si le modèle acteur se justifie, car un service HTTP sans état et une base classique suffisent souvent. Les offres françaises qui citent Akka sont peu nombreuses, et certaines ne mentionnent que Play JSON : faites préciser la part réelle d'acteurs et de cluster dans le poste.
Les compétences à noter chez un développeur Akka / Pekko
- Modèle acteur et API typée
- Supervision et gestion des pannes
- Akka Streams et contre-pression
- Cluster, sharding et split brain
- Persistence et event sourcing
- Play Framework et migration vers Pekko
Des questions tirées de l'exploitation d'un cluster d'acteurs
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un acteur doit appeler une base de données qui répond en 200 ms. Comment l'écrivez-vous sans bloquer le système ?
Une bonne réponseL'appel renvoie un Future, et l'acteur ne l'attend pas : context.pipeToSelf lui renvoie le résultat sous forme de message, et l'état de l'acteur n'est jamais modifié depuis le callback du Future. Si la bibliothèque est bloquante, comme JDBC, l'appel tourne sur un dispatcher dédié et borné, jamais sur le dispatcher par défaut. Un bon profil précise ce que fait l'acteur des messages reçus pendant l'attente : stash, ou un état « en cours ».
Signal d'alerteAwait.result dans l'acteur, ou une variable de l'acteur modifiée dans le onComplete du Future.
Question 2 · senior
Le réseau coupe votre cluster de six nœuds en deux groupes de trois. Que se passe-t-il pour les entités shardées ?
Une bonne réponseChaque groupe voit l'autre comme injoignable. Tant que personne ne décide, les nœuds injoignables ne sont pas retirés et les entités qu'ils portaient restent indisponibles. Si l'on retire les nœuds automatiquement sans précaution, chaque moitié recrée les mêmes entités, et deux copies écrivent dans le journal. Le Split Brain Resolver choisit le côté qui survit selon une stratégie (keep-majority, static-quorum, lease) et arrête l'autre. Avec deux moitiés égales, keep-majority garde celle qui contient le nœud d'adresse la plus basse.
Signal d'alerte« Le cluster se répare tout seul », ou un retrait automatique des nœuds activé sans connaître le risque de deux copies.
Question 3 · senior
Vous devez ajouter un champ à un événement persisté depuis deux ans dans le journal. Comment faites-vous ?
Une bonne réponseLes anciens événements ne sont jamais réécrits. Le champ est ajouté comme optionnel ou avec une valeur par défaut dans le sérialiseur (Jackson, Protobuf), ou un EventAdapter convertit l'ancien format à la relecture. Pour un changement profond, on crée un nouveau type d'événement. Le format de sérialisation doit avoir été choisi pour évoluer, et Java Serialization est exclue.
Signal d'alerteModifier la case class et redéployer, ou lancer un script qui réécrit le journal.
Question 4 · confirmé
Un flux Akka Streams lit Kafka et écrit dans une API externe plus lente. Comment évitez-vous de perdre ou d'empiler des messages ?
Une bonne réponseLa contre-pression ralentit la lecture Kafka quand l'API ne suit pas. mapAsync avec un parallélisme borné pour les appels, throttle si l'API impose un débit, et commit des offsets seulement après l'écriture (committableSource puis Committer). Un RestartSource avec backoff relance le flux après une erreur. Le traitement est au moins une fois, donc l'appel doit être idempotent.
Signal d'alerteCommitter les offsets à la lecture, ou un Source.queue dont le buffer grossit sans limite.
Question 5 · junior à confirmé
Pourquoi l'API typée a-t-elle remplacé les acteurs classiques, et qu'est-ce que cela change dans le code ?
Une bonne réponseUn acteur typé déclare le type des messages qu'il accepte (Behavior[Command]), et le compilateur refuse un message d'un autre type. Le sender() implicite disparaît : la réponse passe par un ActorRef[Reply] glissé dans la commande. Le comportement est une fonction qui renvoie le comportement suivant, ce qui remplace become. La personne sait faire cohabiter les deux API pendant une migration.
Signal d'alerteN'y voir qu'un changement de syntaxe, ou utiliser sender() à l'intérieur d'un Future.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Akka, Pekko et Play : ce que demandent les recruteurs
Akka ou Pekko : que demander dans l'offre ?
Écrivez ce que l'équipe utilise vraiment. Jusqu'à Akka 2.6, les deux API sont presque identiques, donc un profil Akka s'adapte vite à Pekko. Les écarts viennent des versions d'Akka sorties après le fork, que Pekko ne reprend pas, et de la licence : Akka demande une licence commerciale en production dans la plupart des cas, Pekko est sous licence Apache. Si une migration est prévue, dites-le, c'est une compétence à vérifier à part.
Un développeur Scala fonctionnel (Cats, ZIO) convient-il à un poste Akka ?
Il maîtrise le langage et la concurrence, mais le modèle diffère. Akka raisonne en acteurs qui gardent un état et échangent des messages, avec du cluster et de la persistence. Cats Effect et ZIO raisonnent en effets et en fibres. Un bon profil passe de l'un à l'autre, à condition de vérifier en entretien la supervision, le sharding et l'event sourcing, qu'il n'a peut-être jamais pratiqués.
Play Framework doit-il figurer dans les prérequis ?
Seulement si l'API web du poste est en Play et représente une part importante du travail. Play s'apprend vite pour un développeur Scala, alors que la difficulté du poste se trouve dans les acteurs, le cluster et les événements persistés. Certaines offres citent Play JSON, la bibliothèque de sérialisation, sans le framework web. Vérifiez ce point avec l'équipe avant de filtrer les CV sur ce mot.
Comment évaluer la pratique du cluster sans exercice de plusieurs jours ?
Un exercice de conception de 20 minutes en entretien suffit souvent : un système d'entités réparties, avec la panne d'un nœud et l'évolution d'un événement à traiter. Pour le code, un petit acteur typé à écrire ou un acteur classique à relire montre vite les réflexes, comme un état modifié depuis un Future. Un test technique long, à rendre plus tard, apporte peu sur ces sujets.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
