Scaling to 3 Billion Monthly API Requests Without Microservices: A Pragmatic DevOps Journey

Floran Pagliai — Tue, 20 May 2025 16:36:07 +0000

Hi, I’m Floran Pagliai, the first engineer and now CTO at Weglot. When I joined the company back in 2017, it was still an early-stage startup with just a couple of clients, an MVP coded in Silex, and a big ambition: to simplify website translation without requiring technical skills. Today, we handle over 3 billion API requests per month—and we do it with a monolith.

Let me take you through our journey, and why I believe in the power of pragmatic, boring tech to achieve serious scale.

Joining Early, Building Foundations

I came on board as the first developer when Weglot had just raised its seed round. The infrastructure was basic: Remy, our cofounder, was deploying code via FTP using FileZilla. Everything was hosted on a few load-balanced servers, and the app, API, and front-end were built on Silex.

One of my first decisions was to migrate everything to Symfony and begin putting proper CI/CD pipelines in place. We also set up automated testing, started structuring the codebase, and prepared the platform to support growth.

One Billion Requests, One Endpoint

Most of our API traffic goes through a single endpoint: /translate. This endpoint is responsible for fetching, translating, and delivering content. To reduce the load on this critical path, we use Cloudflare to cache responses aggressively. Today, we cache nearly 55% of all traffic at the edge, which means 1.65 billion out of 3 billion monthly requests never hit our origin.

It’s simple: if the response doesn’t change, don’t regenerate it.

No Microservices, No Regrets

We still run a monolithic PHP/Symfony application. No microservices, no serverless sprawl. Why? Because we value mastery and pragmatism over trends.

Everything lives in one codebase, deployed in a single pipeline. It makes reasoning about the system straightforward, it reduces overhead, and allows a small team to move fast. When I talk to engineers at other companies and tell them this, they’re surprised we scale this way. But it's working.

We use MySQL hosted on AWS with Aurora, load balancers to distribute traffic around services, and Datadog for metrics and observability. That’s it. No Kubernetes, no event bus, no tech for tech's sake.

Lessons from Scale

We’ve learned a few things on the way to billions of monthly requests:

Caching is your best friend. Especially when working with expensive services like translation APIs ou LLMs.
Latency matters. We monitor every endpoint in Datadog to detect performance regressions early.
Simplicity wins. Complexity slows you down. If you understand your stack deeply, you can do incredible things with it.
Cloud is worth it. We embraced managed services from day one, which saved us countless ops headaches.

Looking Ahead

That said, things evolve. We're now at a point where it makes sense to gradually break out parts of our monolith into services. We have the team, the tooling, and the operational maturity to take that step without compromising stability.

Why now? Because we're preparing for our next wave of growth. Supporting larger enterprise clients, regionalized infrastructure, and global data compliance will easier with a more modular architecture.

At Weglot, we scale with simplicity. And we’re proof that you don’t need to go micro to go big.

If you have questions about scaling, simplicity, or PHP at scale, I’d love to chat. Drop a comment below or reach out!

If you speak French, this post is extracted from this podcast:

I Built CodeNudge: An AI Reviewer for Your GitHub Pull Requests

Floran Pagliai — Sun, 27 Apr 2025 12:53:54 +0000

Hey devs 👋

Over the past few months, I’ve been working on a side project to solve a real pain I kept seeing in daily development:

Code reviews take too long.
Important feedback sometimes gets missed.
It slows down teams that want to move fast without sacrificing quality.

So I built CodeNudge, a lightweight AI reviewer that integrates directly with GitHub.

What CodeNudge does:

PR Summaries: It automatically summarizes your pull requests so you can understand changes at a glance.
AI Code Reviews: It provides contextual, line-by-line feedback — highlighting improvements, potential issues, or even code style suggestions.
Contributor Insights: It gives you visibility on team contributions and reviews over time.

No need for complicated setups, you just connect your GitHub account and select the repositories you want to monitor.

Why I built it

I realized that most teams either:

Spend too much time reviewing every line manually (and end up fatigued), or
Do superficial reviews just to keep things moving.

Neither of these really serves code quality or developer happiness.

CodeNudge is meant to act like a friendly, tireless reviewer that helps:

Speed up reviews,
Surface important comments earlier,
Let humans focus on higher-level discussions.

What’s next

We’re still in public beta right now, which means your feedback can help shape the product.

I’m actively working on:

More advanced context on review
Custom learnings
More contributions insights

Want to check it out?

👉 Try Codenudge (public beta is live!)

Would love to hear:

What you think of the core idea?
Would you use this in your workflow?
Anything missing that would make it a no-brainer for your team?

Feel free to drop any questions or feedback in the comments! 🙌