Prefers concrete examples over frameworks of the week.
A nightly job pulls a supplier CSV from a partner in Lyon and upserts it into Postgres 15 on a small OVH VPS. About 180k rows, 14 columns, one of them a French product label with embedded semicolons.
We had a booking system on PHP 8.1, running on a mix of app servers in UTC and a couple of legacy boxes still on Europe/London. A nightly report summed "bookings in the next 7 days" and the number was
We run a PHP 8.2 worker pool on Kubernetes, 60 pods, each processing image derivatives from an S3-style bucket. Each job: download, resize with GD, write back. Throughput was fine—about 40 jobs/sec ac
We shipped SMS verification to French users in March. Same code path as everywhere else: E.164 in the database, a small normalization step on input. About 4,000 signups a week from France at that poin
PHP 8.1 on three FPM pools behind an ALB, Debian 11, APCu 5.1.21 with apc.enable_cli=0. We cache a per-currency pricing table built from a 12k-row product matrix; the array is roughly 4MB serialized,
We run a small SaaS with a mostly French user base. Postgres 14.9 on a managed instance in Paris, Django 4.2 in front, connection through PgBouncer in session mode. Last spring a support ticket came i
PHP 8.1, Ubuntu 22.04, php-fpm plus a systemd timer that ran `bin/console billing:charge-due` every five minutes. Table `subscriptions` had about 400k rows, maybe 3k due on any given night. The job to
Two weeks ago our small API (single EU region, Postgres 14, Nginx 1.22 in front, ~40 req/s at peak) started returning 429s to users who insisted they had only refreshed once. The logs told a different
We had a reporting job on PHP 8.1.27, Debian 12, 8 vCPU worker, pulling about 120k invoice rows nightly from MySQL 8.0 and writing a CSV per customer. Each customer's rows came back already ordered by
The service is a small Django app (Python 3.11, psycopg 3.1) on a two-node setup: app containers on OVH in Gravelines, Postgres 15 managed elsewhere. Two months ago we put PgBouncer 1.21 in front of P
We run PHP 8.2.14 on Ubuntu 22.04, PHP-FPM with 32 workers, MySQL 8.0 on the same host. After upgrading a staging box to 8.3.0, one endpoint went from p95 180ms to p95 2.4s. It served paginated JSON:
Our public API serves about 40k requests/day, mostly French users, and until last spring it ran out of a single `eu-west-3` (Paris) region. p50 looked fine at 180 ms from Paris, but p95 from Marseille
Our billing service runs in eu-west-3 (Paris) on a single 4 vCPU instance, Postgres 15 alongside it, roughly 40k webhook events a day from a payment provider. Nothing exotic. In March we saw a pattern
PHP 8.2.13, built-in server (`php -S`), PHP-FPM not involved. A throwaway internal tool: a router script that serves uploaded files, roughly 40k small JSON files on disk, one developer machine, macOS
Two years ago I moved a side project off a big cloud provider onto a 4 GB RAM VPS from a French host (OVH, Roubaix datacenter). The workload is small: a Postgres 15 database, about 40 GB of data, roug