#332.src - Scaler un monolith: 250 devs, 35 000 fichiers et zéro panique avec Quentin de Metz

·55 min·5 clips

How does a company with 250 developers manage a single 35,000-file codebase without descending into chaos?

The episode begins with host Bruno Soulez introducing the podcast and a new MCP tool before framing the core question: how to scale a monolith without panic. Guest Quentin de Metz, CTO and co-founder of Penny Lane, joins. Quentin explains that Penny Lane started six years ago with him as the sole developer and has grown to about 250 engineers serving close to 500,000 companies. The entire web application is a single Ruby on Rails monolith with React on the front-end, comprising 35,000 files. Quentin shares that the monolith is well-accepted internally, though new hires sometimes question why they aren't using microservices. He attributes their comfort to knowing the monolith's strengths and weaknesses from prior experience, including seeing Booking.com's success with a Perl monolith. They deploy to production every 15 minutes using a Git flow with pull requests and green tests, which allows for easy rollbacks and distributes risk. The team is organized into feature teams, each with a product manager and engineers, working on specific product areas. Code ownership is flexible; developers can modify code outside their team's scope, with some files protected by GitHub code owners for mandatory reviews. To maintain code standards, they use 'fellowships'—voluntary groups that define and update guidelines for things like test factories or linter rules. They apply new standards only to new code, not retroactively, to avoid introducing bugs without user value. This leads to multiple standards coexisting in the codebase, managed through documentation and communication. Quentin discusses technical debt, viewing it as a tool that can be accumulated during exploration phases and paid down later in stable product areas. He emphasizes that both monoliths and microservices require serious governance to avoid spaghetti code. On technology choices, they remain committed to Ruby on Rails for the web application and use Python for the data team, as the interface between them is limited. Regarding AI tools like Cursor, Quentin notes the challenge of the monolith's size exceeding context windows but sees value for learning and some coding tasks. He shares that responsibility for code quality is distributed, with senior engineers expected to guide standards, and he as CTO still codes daily and welcomes code reviews from his team. The conversation covers how they ensure time for refactoring through product culture, bug backlog objectives, and aligning incentives with customer satisfaction via NPS scores. They also consider accounting industry cycles, avoiding risky deployments during critical periods like tax filing seasons. Quentin concludes by recommending PostgreSQL documentation as a key resource and stating a preference for spaces over tabs.

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from IFTTD - If This Then Dev