DEV Community: binadit

How to set up website server performance that holds under real traffic

binadit — Fri, 25 Sep 2026 07:53:52 +0000

Your server works fine until it doesn't

Every infrastructure engineer knows this moment: the server hums along fine in staging, then a traffic spike hits production and everything falls over. Requests queue, workers pin at max, response times spike from 200ms to 8 seconds. The usual reaction is to throw more CPU at it. That's rarely the actual problem.

Most servers that collapse under load aren't under-resourced, they're misconfigured. The default settings for PHP-FPM, Nginx, and your database connections were never meant for production traffic. Here's the exact sequence of changes that fixes this, in the order that actually matters.

Step 0: measure before you touch anything

You can't prove a fix worked without a baseline. Run this first:

ab -n 1000 -c 50 https://yourdomain.com/

Record requests per second, mean response time, and failed request count. Check uptime and vmstat 1 5 during the test too. Write it all down; you'll compare against it later.

Fix 1: PHP-FPM is probably misconfigured

The default pool config is not production-ready. Open it:

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

Size your workers based on actual memory usage, not guesswork. Check real footprint per worker with ps aux | grep php-fpm (typically 30-60MB for WordPress/Laravel), then divide available RAM by that number.

pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

pm.max_requests is underrated. It recycles workers periodically, which stops slow memory leaks from degrading your server over hours of uptime.

Fix 2: Nginx is dropping connections it doesn't need to

Reduce TCP handshake overhead with proper keepalive and connection settings:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
}

If you're proxying to PHP-FPM over a Unix socket, bump the backlog to match expected concurrency:

listen = /run/php/php8.3-fpm.sock
listen.backlog = 1024

Fix 3: your database connections are too expensive

Each unpooled connection costs a handshake, auth round trip, and memory allocation. At scale, this is a silent killer. For Postgres, PgBouncer is the standard fix:

sudo apt install pgbouncer

[databases]
yourapp = host=127.0.0.1 port=5432 dbname=yourapp

[pgbouncer]
listen_port = 6432
auth_type = md5
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25

Point your app at port 6432 instead of 5432. This typically cuts connection overhead by 60-80% under concurrent load. MySQL users: look at ProxySQL or mysqlnd_mux.

Fix 4: cache what shouldn't hit the database every time

Install Redis:

sudo apt install redis-server
sudo systemctl enable redis-server

Set eviction policy so it doesn't just run out of memory:

maxmemory 512mb
maxmemory-policy allkeys-lru

For custom apps, wrap expensive queries in a cache-aside pattern:

$cacheKey = "product:{$id}";
$product = $redis->get($cacheKey);
if (!$product) {
    $product = $db->query("SELECT * FROM products WHERE id = ?", [$id]);
    $redis->setex($cacheKey, 300, serialize($product));
}

Fix 5: stop static assets from hitting your app server

location ~* \.(jpg|jpeg|png|gif|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

If there's a CDN in front, confirm it respects your origin headers instead of overriding with its own default TTL.

Verifying it actually worked

Re-run the same load test, same concurrency:

ab -n 1000 -c 50 https://yourdomain.com/

Compare against baseline. RPS should climb, often 30-100%. Response time variance between p50 and p95 should tighten. Failed requests should hit zero at your target concurrency.

Watch PHP-FPM workers scale during load:

watch -n 1 'ps aux | grep php-fpm | wc -l'

Workers should scale up smoothly and settle, not spike immediately to max_children and stay there. If they pin instantly, either your sizing is wrong or a slow query is holding connections open too long.

Check PgBouncer is actually in the path:

psql -h 127.0.0.1 -p 6432 -U youruser yourapp -c "SHOW POOLS;"

And check Redis hit rate:

redis-cli info stats | grep keyspace

Healthy cache-aside logic should show above 80% hit ratio within minutes.

Mistakes that undo all of this

Oversizing max_children. More workers than RAM supports causes swapping, which is worse than queued requests.
Caching without invalidation. Stale cached data is a harder bug to catch than a slow endpoint. Always set a TTL or invalidate on write.
Pooling without adjusting app-level assumptions. Transaction-mode pooling breaks session-level features like advisory locks if your app still expects a persistent connection.
Skipping the baseline. No before/after numbers means no proof anything worked.

This isn't a full re-architecture. It's five configuration changes applied in order, with measurement at each step. That's usually enough to take a server from falling over at the first spike to handling concurrency predictably.

Full walkthrough with more context: How to set up website server performance that holds under real traffic

Originally published on binadit.com

Your email is GDPR-compliant today. Will it still be next year?

binadit — Sun, 20 Sep 2026 13:07:11 +0000

Your GDPR compliance depends on a court case you're not tracking

Here's an uncomfortable fact: the legal basis for your Google Workspace or Microsoft 365 email is a single framework that's currently being challenged in front of the same court that already killed its two predecessors. If you run infrastructure or make hosting decisions, this is worth ten minutes of your time.

Ask your IT partner if EU email in a US productivity suite is GDPR-compliant and you'll get a confident yes: both providers are certified under the EU-US Data Privacy Framework. Technically true. Also missing the point.

The legal stack, in short

Sending personal data to a US company is a "transfer" under GDPR Chapter V (Articles 44-50).
That's only lawful today because of the EU-US Data Privacy Framework (DPF), adopted July 2023.
Its two predecessors, Safe Harbor and Privacy Shield, were both struck down by the Court of Justice of the EU (CJEU).
The DPF is now under appeal at that same court.

Three attempts. Two collapses. One pending verdict. That's not a stable foundation to build a compliance program on.

"We use an EU data center" doesn't fix it

This is the part engineers get wrong most often. Region selection is not jurisdiction. Under the US CLOUD Act, a US company has to hand over data it controls when a US authority demands it, regardless of which data center it's sitting in. A Frankfurt or Amsterdam region owned by a US parent is still in scope.

Don't take my word for it. In June 2025, Microsoft France's director of legal affairs testified under oath before a French Senate inquiry. Asked directly if he could guarantee French citizens' data would never be handed to the US government without French authorization, his answer was: "No, I cannot guarantee that."

That's the provider, on the record, under oath.

Where things stand right now

A challenge to the DPF (Latombe v. Commission) was dismissed by the General Court in September 2025, but only on facts as they existed in 2023. Nothing since then was considered. It's now on appeal to the CJEU.
Microsoft was granted leave to intervene in that appeal. A company doesn't intervene in EU court proceedings unless it has serious skin in the game.
The US oversight board that underpins the DPF (PCLOB) has been without quorum since January 2025.
In June 2026, the US Supreme Court ruled FTC commissioners can be removed at will by the President. The FTC is the enforcement body for the DPF on the US side.
FISA Section 702, the surveillance law at the center of the original Schrems II ruling, lapsed in June 2026 after failed extensions. Collection continues under existing court certifications regardless.

None of this means the DPF will definitely fall. It means your compliance posture depends on a decision you don't control, on a timeline you can't predict. Last time this happened (Schrems II, July 2020), companies had zero notice and a three-year gap before a replacement existed.

The AI layer adds more surface area

Copilot and Gemini are now embedded directly in mail and file storage. That's more data flows to account for:

# Questions worth asking your provider contract, literally:
- Does input get used for model training? (check tier, not marketing page)
- Can you delete a specific individual's data from a trained model? (usually no)
- Do you know which model processed which record, in which region?

The EU AI Act's transparency rules are already active (since August 2026). The heavier documentation requirements for HR, credit, and access-to-services use cases were pushed to December 2027, but that's a delay, not a way out. If you can't answer the questions above today, you won't be able to answer them then either.

The actual fix

If email, calendar, and file storage sit with a provider incorporated and operating entirely in the EU, no CLOUD Act exposure exists because there's no US legal entity to compel. That's not a mitigation, it's the absence of the transfer problem entirely.

As a data point: a Dutch provider offering this setup starts at €1.99 per mailbox per month, often cheaper than what teams already pay for Workspace or M365 licensing.

Practical takeaway

Check who actually handles mail for your domain (MX records will tell you the provider, not the jurisdiction, but it's a start). Then ask your provider the same question the French Senate asked Microsoft: can you guarantee this data is never handed over without our government's consent? If the answer is "no, but it hasn't happened," that's not a compliance guarantee, that's a probability bet.

Full breakdown of the legal timeline and case law: Your email is GDPR-compliant today. Will it still be next year?

Originally published on binadit.com

Solving the deploy frequency wall: from weekly releases to multiple daily deploys without new incidents

binadit — Fri, 18 Sep 2026 07:59:30 +0000

Why your team keeps reverting to weekly deploys (and how to actually fix it)

Here's a pattern that shows up constantly in teams of 15-40 engineers: leadership pushes for faster releases, the team bumps deploy frequency up, and within a few weeks someone quietly walks it back to weekly. No mandate, no meeting. Just two or three rough releases in a row, and the team self-polices back to "safe" cadence.

It looks like a discipline problem. It isn't. It's an infrastructure problem, and it's fixable.

The real issue: your pipeline was built for a different era

When you deploy weekly, you can afford sloppiness because a human has time to babysit each release. Watch the error rate for 20 minutes, glance at a dashboard, ship it. Try that five times a day and the manual check either disappears or becomes theater nobody trusts.

Under the hood, this usually comes down to four coupled problems:

Deploys aren't atomic. Code, migrations, and config all ship in one shot. If the migration is slow, the code can't go out without it.
Rollback means redeploying. Reverting takes the same pipeline, the same time, the same risk as deploying forward.
Monitoring lags deploy speed. Alert thresholds and log delays were tuned for hourly checks, not minute-by-minute validation.
Blast radius is 100%. Every deploy hits the whole fleet at once, so any bad release is automatically a full incident.

None of this is about code quality or test coverage. It's about the deploy path, routing layer, and monitoring stack not being built for the frequency you're asking of them.

The fix: decouple, automate rollback, shrink the blast radius

1. Split schema changes from code deploys

Migrations are usually the biggest source of deploy anxiety. Use the expand/contract pattern so schema changes never ship in the same step as code:

-- Step 1: expand (safe, backward compatible)
ALTER TABLE orders ADD COLUMN shipping_method_v2 VARCHAR(50) NULL;

-- Step 2: dual-write in app code, backfill
UPDATE orders SET shipping_method_v2 = shipping_method WHERE shipping_method_v2 IS NULL;

-- Step 3: contract (separate deploy, days later)
ALTER TABLE orders DROP COLUMN shipping_method;

Code deploys stop waiting on migrations, and migrations stop blocking rollbacks.

2. Make rollback a routing flip, not a redeploy

If reverting means rerunning the pipeline backward, people will hesitate to ship under pressure. Rollback should be a traffic switch, done in seconds:

# Nginx upstream weight shift for canary rollback
upstream backend {
    server app-v124-1:8080 weight=0;   # new version, was live
    server app-v123-1:8080 weight=100; # previous stable, restored
}
# reload takes effect in under 1 second
nginx -s reload

Or on Kubernetes:

kubectl rollout undo deployment/checkout-api
kubectl rollout status deployment/checkout-api --timeout=30s

Ship to a small slice of instances first. Healthy? Shift more weight over. Not healthy? Shift back to zero. No twelve-minute rebuild required to recover.

3. Automate the canary check

A human staring at Grafana for 20 minutes works at weekly cadence. At five deploys a day, it's neither sustainable nor reliable, people get worse at spotting anomalies the more times they repeat the check.

canary:
  metrics:
    - name: error_rate
      threshold: baseline + 0.5%
      window: 5m
    - name: p95_latency
      threshold: baseline + 15%
      window: 5m
    - name: 5xx_count
      threshold: baseline + 10
      window: 5m
  action_on_fail: auto_rollback
  promotion_steps: [5%, 25%, 50%, 100%]
  step_duration: 5m

This is probably the single highest-leverage change for teams moving to daily deploys. It turns a subjective judgment call into a repeatable gate.

4. Shrink the blast radius with progressive rollout

Deploying to 100% of instances at once makes every release a full-fleet bet. Instead:

Ship to 5% of instances or one availability zone
Hold through a full traffic cycle, including cron jobs and batch work
Auto-promote on healthy metrics, auto-rollback on bad ones
Only reach 100% after clearing every stage

Same principle as safe database migrations: keep each irreversible step small.

How to know it actually worked

Don't just track "deploy success." Watch these specifically:

Change failure rate: percentage of deploys triggering a rollback or hotfix. Aim under 15% (DORA elite benchmark), trending down as frequency goes up.
MTTR: with automated rollback via traffic weight shift, this should drop under 5 minutes.
Rollback execution time: measure from "threshold breached" to "traffic fully reverted." Should be seconds to low minutes, not tied to build time.
Canary false negative rate: how often something bad slips past the gate and gets caught by users instead. If it happens more than once a quarter, retune thresholds, don't remove the gate.
Deploy frequency vs. incident count: these two lines should decouple. If incidents still climb with frequency, your canary metrics are probably missing a business signal like checkout completion or cart abandonment.

Give this at least four weeks at the new cadence before declaring victory. One good week proves nothing.

Keeping it from backsliding

Alert on deploy frequency itself. A quiet drop without an explicit decision usually means the pipeline is causing avoidance.
Treat canary thresholds as living config, not a one-time setup. Traffic patterns shift, thresholds need to shift with them.

Full technical breakdown, including the zero-downtime migration mechanics: read the original article

Originally published on binadit.com

How to stabilize a system while it is actively failing

binadit — Wed, 16 Sep 2026 07:32:01 +0000

Stop diagnosing, start stabilizing: a field guide for live incidents

Your error rate just spiked. Someone is already asking "what changed?" in Slack. Here's the uncomfortable truth: the fastest way to make an incident worse is to start debugging the root cause before you've stopped the bleeding. This is the sequence we use to stabilize production systems first and investigate second, whether that's a single Node server or a full multi-node setup behind a load balancer.

The two mistakes that make incidents worse

Under pressure, teams almost always do one of these:

Change too many things at once, so nobody can tell what fixed (or broke) what
Start root-causing before the system is even stable

Everything below exists to prevent those two mistakes.

What you need before an incident happens

You can't stabilize what you can't see or touch. Minimum bar:

Shell access to affected hosts (SSH or a bastion)
Basic monitoring: CPU, memory, disk I/O, error rates (Prometheus, Datadog, or even htop plus logs)
A load balancer or reverse proxy in front of the app (Nginx, HAProxy, cloud LB)
A known, tested rollback procedure
A second person to sanity-check decisions, even just in a Slack thread

If you're missing any of this, that's your next project, not something to build mid-incident.

Step 1: freeze all changes

This isn't technical, it's procedural. Post this immediately:

INCIDENT: elevated error rate on checkout-api since 14:32 UTC.
No deploys, no config changes, no manual DB edits until stabilized.
Incident channel: #inc-2024-checkout

This stops the classic "quick fix" from a well-meaning teammate that stacks a second problem on top of the first one you haven't diagnosed yet.

Step 2: check what changed in the last 24 hours

Most live failures trace back to something recent: a deploy, a config edit, a traffic spike, or an upstream update.

# Recent deploys
git log --since="24 hours ago" --oneline

# Recent config changes (if infra is version controlled)
git -C /etc/nginx log --since="24 hours ago"

# System-level changes
last -x | head -20
cat /var/log/dpkg.log | grep "$(date +%Y-%m-%d)"

If timing lines up, roll back before you dig further:

# Tagged release rollback
git checkout tags/v2.14.1
./deploy.sh production

# Kubernetes rollback
kubectl rollout undo deployment/checkout-api

Step 3: shed load before you preserve correctness

No obvious recent change, or the rollback didn't help? Reduce load on the failing component. You're trading functionality for stability, temporarily.

Ordered roughly by disruption:

Rate limit at the edge (per IP or per token)
Kill non-critical endpoints: recommendations, analytics beacons, background reports
Maintenance page for non-essential routes, keep checkout/login alive
Scale horizontally if the bottleneck is compute, not a shared resource

Emergency Nginx rate limit:

limit_req_zone $binary_remote_addr zone=emergency:10m rate=5r/s;

server {
    location /api/ {
        limit_req zone=emergency burst=10 nodelay;
        limit_req_status 503;
        proxy_pass http://backend;
    }
}

nginx -t && nginx -s reload

Step 4: the database goes first

Databases usually fail last and recover slowest. A saturated DB will keep everything else unstable no matter what you fix upstream.

-- Connections vs max
psql -c "SELECT count(*) FROM pg_stat_activity;"
psql -c "SHOW max_connections;"

-- Long-running queries
psql -c "SELECT pid, now() - query_start AS duration, query
         FROM pg_stat_activity
         WHERE state = 'active'
         ORDER BY duration DESC LIMIT 10;"

Kill runaway queries holding locks:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE pid = 14832;

If connection exhaustion is the pattern, PgBouncer fixes this without touching app code. No pooler running? That's your action item once the fire's out.

Step 5: fail over instead of fighting a bad node

Disk pressure, memory leak, bad kernel state on one box: pull it from rotation instead of debugging it live.

# HAProxy
echo "disable server backend/web03" | socat stdio /var/run/haproxy.sock

# Kubernetes
kubectl cordon node-3
kubectl drain node-3 --ignore-daemonsets --delete-emptydir-data

Once it's out of rotation, it's a forensic artifact you can inspect at your own pace, not a liability sitting in the traffic path.

Step 6: communicate facts, not guesses

STATUS 15:10 UTC: error rate back to baseline (0.2%) after rolling back
deploy v2.14.2 and draining node-3. Root cause under investigation.
Next update in 30 min or on change.

Don't close the incident the second the dashboard looks calm.

How to actually verify stability

One green graph isn't proof. Hold these steady for 30 to 60 minutes at real traffic:

Error rate: back to baseline, checked in 5-minute buckets, not instant values
Latency: p50, p95, and p99 all recovered, a good average can hide a bad p99
Resource headroom: CPU, memory, connection pools have actual margin
Queue depth: backlogs draining, not just growing slower

# Nginx status code breakdown
tail -n 5000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c

# Live connection stats
watch -n 2 "ss -s"

# DB connection headroom
psql -c "SELECT count(*), max_conn FROM pg_stat_activity, (SELECT setting::int AS max_conn FROM pg_settings WHERE name='max_connections') s GROUP BY max_conn;"

Compare current traffic-normalized error rate to the same time last week, not to five minutes ago. Post-load-shedding quiet periods lie.

Pitfalls to avoid

Root-causing mid-incident: adds risk, rarely speeds recovery
Rolling back and rolling forward in the same window: give one change time to prove itself
Declaring victory too early: five calm minutes isn't a stable system
Skipping the change freeze: uncoordinated fixes are how you get two incidents instead of one

Stabilize first. Root-cause after. Every time.

Full original write-up with more context: binadit.com

Originally published on binadit.com

From 4.2s to 380ms: debugging latency in a high availability infrastructure setup

binadit — Fri, 11 Sep 2026 07:05:45 +0000

Five silent bottlenecks that turned a 400ms API into a 4.2s crawl

No deploys. No schema changes. No new integrations. Just a scheduling and resource-planning SaaS with 40k users watching its p95 response time climb from 400ms to 4.2 seconds over six months. Nobody could point to a cause, because there wasn't one big cause, there were five small ones stacked on top of each other.

This is the writeup of how we found and fixed them, without a rearchitecture.

The symptoms before the numbers existed

Support tickets called the dashboard "laggy" long before anyone had hard metrics. By the time it got measured:

p95 latency: 400ms to 4.2s over ~6 months
Trial-to-paid conversion down 11% in the same window
Sales getting asked about performance during renewals

The team had already tried the usual moves: bigger instances, a read replica, scheduled restarts. None of it held. When scaling vertically twice does nothing, that's a strong signal the problem is architectural, not capacity.

Step one: measure before touching anything

We spent the first week purely on instrumentation, tracing requests across the API gateway, app servers, database, and cache layer under normal load. No fixes yet. Changing the system while you're trying to measure it just adds noise.

Five issues surfaced. None of them alone explained 4.2 seconds, but together they did.

The five issues

1. N+1 queries in a hot path

A dashboard endpoint fetched a customer's project list, then hit the DB once per project for status. 40 projects meant 41 round trips for one page load.

2. Connection pool exhaustion

8 app servers x 20 connections each = 160 possible connections, against a Postgres max_connections of 100. At peak, requests queued for a connection slot before a query even ran.

3. Cache invalidation nuking whole namespaces

Redis had a 30s TTL on project status, reasonable on paper. But a background job flushed entire cache namespaces on any write, including unrelated ones. Actual hit ratio: 34%.

4. Cross-AZ chatter

App tier and Redis cluster weren't pinned to the same AZ. ~40% of Redis calls crossed zones, adding 2 to 4ms each. At volume, that's hundreds of milliseconds per request.

5. A synchronous third-party call in the request path

A usage-tracking webhook to an external analytics provider ran synchronously inside the request cycle. On a bad day that provider took 800ms to 1.5s, and every request waited on it.

How we prioritized fixes

Impact vs. risk, not ease of implementation:

Sync third-party call, high impact, low risk
N+1 queries, high impact, low risk
Connection pool exhaustion, high impact, medium risk
Cache invalidation, medium impact, medium risk
Cross-AZ placement, medium impact, low risk

We explicitly skipped touching instance sizes again. Two rounds of vertical scaling with zero improvement was itself the data point: the bottleneck was I/O and architecture, not compute.

We also shipped fixes one at a time, measuring after each. Bundling everything into one release makes it impossible to know what actually helped, or what quietly broke something else.

The fixes

Move the analytics call off the request path

// before: synchronous call blocking the response
await analyticsClient.track(event); // 800ms-1.5s on slow days
return response;

// after: fire-and-forget via queue
await queue.push('analytics.track', event); // ~2ms
return response;

Used the existing Redis infra as the queue backend, no new dependency. A worker process handles delivery with retries and a dead-letter queue. This alone cut 800ms to 1.5s off the median request on affected endpoints, and when the analytics provider had two outages during the engagement, users never noticed.

Kill the N+1

-- before
SELECT * FROM projects WHERE account_id = $1;
-- then per project:
SELECT * FROM project_status WHERE project_id = $1;

-- after
SELECT p.*, s.status, s.updated_at
FROM projects p
JOIN project_status s ON s.project_id = p.id
WHERE p.account_id = $1;

41 round trips became 1. Query time for that endpoint went from ~620ms to ~45ms average.

Retune the connection pool

Dropped per-server pool size from 20 to 12 (8 x 12 = 96, under the 100 limit) and added PgBouncer in transaction pooling mode:

[databases]
app_db = host=127.0.0.1 port=5432 dbname=app_production

[pgbouncer]
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25
reserve_pool_size = 5
reserve_pool_timeout = 3

Connection wait time went from ~180ms average at peak to under 5ms.

Fix cache invalidation

Switched from namespace-wide flushes on any write to key-level invalidation tied to the specific project changed. Kept the 30s TTL as a safety net, but it stopped being the primary mechanism.

Cache hit ratio: 34% to 91% within a week. Small diff, outsized effect on database load.

Takeaway

None of these fixes were exotic. This is what accumulated technical debt looks like in a system that grew for a few years without a dedicated performance pass. If your latency crept up gradually with no single obvious cause, look for a stack of small architectural issues before you reach for bigger hardware.

Full writeup with more detail: Debugging latency in a high availability infrastructure setup

Originally published on binadit.com

How Docker networking broke checkout under load: a container ecommerce infrastructure case study

binadit — Wed, 09 Sep 2026 07:02:54 +0000

Checkout was timing out at 900 req/s, and it had nothing to do with CPU

A marketplace client came to us with a scary but familiar symptom: checkout p95 latency jumping from 280ms to over 2.1 seconds during traffic spikes. Their instinct was to throw more containers at it. That made things worse. Here's what was actually going on, and how we fixed it without touching a line of application code.

Link to the full writeup: Docker networking broke checkout under load

The setup

PHP monolith, containerized about a year prior, running on a single host via Docker Compose: app containers, Redis, a worker queue, behind a managed load balancer. 40k DAU, peak ~900 req/s. It ran fine for six months. Then flash sales started producing "the site is freezing" tickets.

The team's first move was scaling app containers, assuming CPU/memory pressure. Query times on Postgres stayed stable at 8-14ms the whole time, so the database wasn't the culprit either. The bottleneck was hiding in the network layer between containers, a place default tooling barely gives you visibility into.

What the audit found

Three compounding issues, none fatal alone:

1. Default bridge network overhead. Every inter-container hop (app to Redis, app to Postgres, app to search) was going through userland proxying on the default bridge. We measured ~1.8ms added latency per hop. At 900 req/s with 3-4 internal calls per request, that adds up fast.

2. Conntrack table exhaustion. nf_conntrack_max was still at the kernel default of 65,536. Short-lived Redis/Postgres connections churned through the table during spikes, filled it, and the kernel silently started dropping packets. Nobody noticed because syslog wasn't shipped anywhere useful.

3. DNS resolution overhead. Docker's embedded DNS (127.0.0.11) was resolving service names on every new connection instead of the app caching results. Under load, with connection churn, lookups started queuing behind each other.

None of these show up with 10 test users in staging. All three show up hard with 900 real ones under concurrent load.

What we didn't do

We ruled out "just move to Kubernetes." It wouldn't have fixed anything here; K8s has its own version of the same problems (CNI choice, kube-proxy mode, CoreDNS caching). Swapping orchestrators without fixing the root cause just relocates it.

We also ruled out rewriting the app to reduce internal calls. The call pattern was normal. The network layer needed to handle it efficiently, not the other way around.

The fix, in four layers

Kernel tuning for conntrack:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 4096

Applied via /etc/sysctl.d/99-docker-network.conf and sysctl --system. We also started monitoring conntrack table utilization going forward, since a full table fails silently.

Moved internal traffic off the default bridge:

docker network create \
  --driver bridge \
  --opt com.docker.network.bridge.enable_icc=true \
  --opt com.docker.network.driver.mtu=9000 \
  --subnet 172.28.0.0/16 \
  internal-services

App containers, Redis, and the search sidecar moved onto this network, keeping east-west traffic off Docker's default NAT path. The public-facing load balancer stayed on a separate network; no change to external attack surface.

Local DNS caching with dnsmasq as a sidecar:

# dnsmasq.conf
no-resolv
server=127.0.0.11
cache-size=1000
local-ttl=10
neg-ttl=5

A 10-second TTL absorbed connection churn during spikes without causing stale resolution issues when containers got replaced on deploy. We specifically tested that a container restart got picked up within one TTL window.

PgBouncer for connection pooling:

[databases]
marketplace = host=postgres-primary port=5432 dbname=marketplace

[pgbouncer]
pool_mode = transaction
max_client_conn = 2000
default_pool_size = 50

This was sequenced last on purpose. Fewer short-lived connections means fewer conntrack entries and fewer DNS lookups, so it made everything upstream easier once the network layer was already sound.

Takeaway

If your containerized app slows down only under load and CPU/memory graphs look fine, stop scaling containers and go look at conntrack, your bridge driver, and DNS resolution behavior. That's usually where it's actually hiding.

Originally published on binadit.com

Solving the real ROI question behind moving off US hyperscalers

binadit — Wed, 02 Sep 2026 07:23:04 +0000

Why your hyperscaler exit math keeps failing finance review

You run the numbers on leaving AWS. Compute is cheaper elsewhere. Storage is cheaper elsewhere. Then finance asks about egress fees, migration hours, and cutover risk, and the whole business case falls apart. Sound familiar? This isn't a bad migration plan, it's a broken cost model.

Most engineers comparing hyperscaler costs against alternatives only look at list prices for compute and storage. That's maybe 40% of the real picture. Here's the rest of it, and a framework to fix your ROI math.

Why the comparison breaks down

Hyperscalers don't really compete on compute price. They compete on making it painful to leave. That's baked into the architecture, not just the contract.

Egress fees are the real anchor. AWS charges roughly $0.09/GB after the first GB out. For a platform pushing 50TB/month (video, API responses, backups, CDN pulls), that's about $4,500/month just to move data, before touching anything else. This fee isn't about bandwidth cost, bandwidth is cheap. It's a moat.

Managed services lock you in harder than compute does. If you're on RDS, DynamoDB, SQS, and Lambda, you're not renting VMs, you're depending on proprietary APIs. Migrating off means rewriting your data access layer, not just moving instances. This is the line item most spreadsheets underestimate by 3-5x.

Reserved instance pricing hides a bad assumption. Finance often compares a competitor's list price to a hyperscaler's 3-year reserved rate and calls it a win for the hyperscaler. But that rate assumes flat usage for 36 months. Most SaaS workloads have seasonal spikes and growth curves. A 3-year commitment is a liability wearing a discount's clothes.

Support cost is invisible until you actually need it. A named TAM tier starts around $15,000/month, and you're still in a ticket queue for anything real. Compare that to a partner where a senior engineer just picks up.

The fix: five cost categories, not one

1. Baseline 12 months of actual spend, not one month

aws ce get-cost-and-usage \
  --time-period Start=2024-11-01,End=2025-11-01 \
  --granularity MONTHLY \
  --metrics 'UnblendedCost' \
  --group-by Type=DIMENSION,Key=SERVICE

Break it into compute, storage, egress, managed services, support, and RI amortization. Egress alone is usually 8-15% of total spend for content-heavy platforms, and it almost never makes the first draft of a migration business case.

2. Model the actual migration cost

This means:

Engineering hours to replace managed-service dependencies (DynamoDB to Postgres, Lambda to containers, SQS to self-hosted queues)
One-time data transfer cost to move the dataset out
Parallel-run cost during validation (typically 4-8 weeks)
A downtime contingency line, even with a zero-downtime plan

For a mid-sized SaaS app with a 2TB database and 15 microservices, expect 200-450 engineering hours. At 80 euros/hour loaded cost, that's 16,000-36,000 euros, upfront. Put it in the model.

3. Recalculate egress under the new architecture

# AWS us-east-1 to internet: $0.09/GB after first 1GB free
# EU provider with peering to major IXPs: $0.01-0.02/GB typical

# 50TB/month egress:
# AWS: 50,000GB * $0.09 = $4,500/month
# EU provider: 50,000GB * $0.015 = $750/month
# Annual difference: $45,000

Colocate with your CDN's regional PoPs and egress typically drops 40-70%.

4. Swap proprietary APIs for open standards

This is the highest-leverage move in the whole exit. It's what makes the savings durable instead of a one-time discount you slowly erode by re-adopting vendor tooling:

DynamoDB → PostgreSQL or self-managed MongoDB
Lambda → containers on Kubernetes or Nomad
SQS/SNS → self-hosted RabbitMQ or Kafka
CloudWatch → Prometheus + Grafana

5. Cut over with zero downtime

Replicate continuously, run both environments in parallel, lower DNS TTL ahead of time, keep the old environment warm for at least one billing cycle.

# 48-72 hours before cutover
example.com.  300  IN  A  203.0.113.10

# Monitor both origins during cutover
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://old-origin.example.com/health
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://new-origin.example.com/health

For database-backed apps, run logical replication for days beforehand, not a single export/import window.

How to know it actually worked

Track these for at least two full billing cycles:

Total spend vs. your 12-month baseline, normalized for traffic growth
Egress as % of total spend (expect 8-15% → 2-4% with good peering)
p95/p99 latency on your top 10 endpoints, before and after
Error rate and uptime, 30 days before vs. 30 days after
Engineering hours on infra ops per month

One sanity check that matters: if spend drops 30% but p99 latency degrades 25%, you haven't won anything. You've just shifted cost into a metric that'll eventually cost you conversions.

Full framework and migration mechanics in the original piece: Solving the real ROI question behind moving off US hyperscalers

Originally published on binadit.com

How to move ecommerce infrastructure from a single VPS to HA without rewriting the application

binadit — Wed, 26 Aug 2026 07:22:59 +0000

Your VPS will fail at the worst possible time

Here's an uncomfortable truth: that single VPS running your store isn't a matter of if it fails, it's when. A kernel update reboot, a Black Friday memory spike, a disk that fills up overnight. None of these are exotic failure modes, they're Tuesday.

The good news: fixing this is an infrastructure problem, not a rewrite. If you're running PHP, Node, or Python against a relational database, you can go from one box to a highly available setup without touching your application code. This applies whether you're on WooCommerce, Magento, or something custom.

Before you touch anything

Check these boxes first:

Your app can run statelessly across multiple servers (or can be made to, sessions and uploads are the usual culprits)
You have root, not just FTP
You've scheduled a maintenance window for DNS and DB cutover
You have a tested, recent backup
You know your traffic pattern: peak RPS, DB connections, payload size

This walkthrough assumes a LAMP/LEMP-ish stack: Nginx or Apache, PHP-FPM or Node, MySQL or Postgres, Redis. Swap tooling as needed for other stacks, the pattern holds.

Step 1: Get state off local disk

This is the real blocker to scaling horizontally. Local disk state has to go before you add a second server.

Sessions → move to Redis:

; php.ini
session.save_handler = redis
session.save_path = "tcp://10.0.0.5:6379"

Uploaded media → object storage (S3-compatible) or shared NFS. For WooCommerce, WP Offload Media handles this out of the box. For custom apps, swap filesystem writes for an SDK call:

$s3->putObject([
    'Bucket' => 'store-uploads',
    'Key'    => $filename,
    'Body'   => fopen($tmpPath, 'r'),
]);

Cache → Redis or Memcached instead of local disk/OPcache-only.

Step 2: Put a load balancer in front, even with one backend

Spin up a small VM or a managed LB now, before you have a second server. Point DNS at the LB's IP immediately. This decouples DNS from your server count forever, no more DNS changes for future scaling.

upstream app_servers {
    server 10.0.0.10:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.11:80 max_fails=3 fail_timeout=30s backup;
}

server {
    listen 443 ssl;
    server_name shop.example.com;
    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Step 3: Clone the app server

Once sessions and media are externalized, your app server is basically stateless. Build a second node from the same provisioning script, Ansible, Docker, or a shell script, doesn't matter, just make it reproducible.

# minimal provisioning sanity check
php -v
nginx -v
composer --version
cat /etc/php/8.2/fpm/pool.d/www.conf | grep pm.max_children

Add it to the upstream block, drop the backup flag, confirm both nodes handle real traffic before moving to the database layer.

Step 4: Replicate the database

Highest-risk step. Set up primary-replica replication or move to a managed cluster.

# primary my.cnf
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = shop_production

# replica my.cnf
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log

CHANGE MASTER TO
  MASTER_HOST='10.0.0.5',
  MASTER_USER='replicator',
  MASTER_PASSWORD='***',
  MASTER_LOG_FILE='mysql-bin.000003',
  MASTER_LOG_POS=154;
START SLAVE;

Check lag before cutover:

SHOW SLAVE STATUS\G
-- Seconds_Behind_Master should be 0

Once stable, cut over writes using a virtual IP or ProxySQL, not a manual config edit during an incident.

Step 5: Real health checks, not port pings

upstream app_servers {
    server 10.0.0.10:80 max_fails=2 fail_timeout=10s;
    server 10.0.0.11:80 max_fails=2 fail_timeout=10s;
}

# haproxy / nginx plus
option httpchk GET /health
http-check expect status 200

Your /health endpoint needs to actually check dependencies:

try {
    $pdo = new PDO($dsn, $user, $pass);
    $redis = new Redis();
    $redis->connect('10.0.0.5', 6379);
    http_response_code(200);
    echo 'ok';
} catch (Exception $e) {
    http_response_code(503);
    echo 'unhealthy';
}

Prove it actually works

Don't trust the config, test it:

Kill a node during low traffic, confirm the LB routes around it inside your fail_timeout window and response times stay flat
Watch Seconds_Behind_Master during peak checkout load, not just idle
Load test both nodes: ab -n 5000 -c 50 https://shop.example.com/ and diff the access logs
Simulate a DB failover in staging, measure reconnect time (should be seconds, not minutes)

Baseline to aim for: zero customer-visible errors when one app node dies, database failover under 30 seconds with retry logic in place.

Mistakes that will bite you

Sticky sessions instead of externalized sessions: works fine until a node dies and half your logged-in users get booted
Duplicate cron jobs: order processing and cache warming running on both nodes doubles the work, pin them to one node or use a job queue
Shallow health checks: pinging port 80 says nothing about whether the DB connection is alive
Replication as a backup strategy: it protects against hardware failure, not against a bad DELETE that replicates instantly
Never testing failover: the first failover shouldn't happen during a real outage

Full walkthrough with more context here: How to move ecommerce infrastructure from a single VPS to HA without rewriting the application

Originally published on binadit.com

Measuring what FISA 702 reauthorization actually changes for EU SaaS infrastructure

binadit — Fri, 21 Aug 2026 08:24:39 +0000

Your "EU region" toggle probably isn't doing what you think

Here's an uncomfortable fact: setting your AWS region to eu-central-1 does nothing to shield you from FISA 702. None of it. If your provider is a US company, that data can still be compelled, regardless of which data center it physically sits in. We ran the numbers to find out what it actually takes to fix this, and whether the fix costs you performance.

FISA 702 got reauthorized in April 2024, running through 2026. It'll come up again, and every time it does, compliance teams ask engineering the same question: can we safely keep running on US-owned cloud infra? The answer isn't legal, it's architectural.

The setup

We benchmarked the same Laravel API workload (PostgreSQL 16, Redis 7, object storage) across three configs:

Config A: AWS eu-central-1, standard hyperscaler, US-headquartered
Config B: EU-owned provider (OVHcloud), data residency guarantees
Config C: Dedicated private cloud, Rotterdam data center, no shared hyperscaler control plane

Same hardware baseline everywhere: 8 vCPU / 32GB app nodes, NVMe DB nodes at 4 vCPU / 16GB, PgBouncer in front of Postgres, Nginx 1.25 as reverse proxy.

Load generated with k6, from a Frankfurt runner to kill long-haul network noise as a variable:

// k6 load profile
export const options = {
  stages: [
    { duration: '10m', target: 2000 }, // ramp 50 -> 2000 VUs
    { duration: '20m', target: 2000 }, // sustained peak
  ],
};
// mix: 70% GET, 30% POST/PUT

We measured two separate things: raw performance, and legal exposure surface (who can be compelled to hand over your data, under what instrument, with or without notifying you).

Result 1: performance is basically a wash

Config	p50	p95	p99	Max sustained req/s
A: AWS eu-central-1	42ms	118ms	210ms	3,150
B: OVHcloud (EU)	47ms	134ms	245ms	2,890
C: Private cloud (Rotterdam)	39ms	102ms	178ms	3,020

The private cloud setup wins on tail latency, but only by 15-20%. If you're picking your infra provider based on speed alone, don't bother, the difference is inside normal variance for most apps. This is not a performance decision.

Result 2: the legal exposure gap is real and it's structural

Config	Subject to FISA 702	Compellable without notifying you	Legal instrument
A: AWS eu-central-1	Yes	Yes, gag orders are standard	FISA 702 + CLOUD Act
B: OVHcloud	No direct exposure, but sub-processor risk	Depends on your stack	GDPR only, if fully EU-owned
C: Private cloud	No	No	GDPR + Dutch law only

Here's the part that should worry you: 60% of the "EU cloud" test deployments we checked were still routing through US-owned CDNs, DNS, or email providers. You think you're compliant because your DB lives in an EU region, but your DNS resolver, your CDN, and your transactional email are all silently reintroducing FISA 702 exposure.

The region setting is not the control point. The corporate parent of every vendor in your chain is.

What it actually costs to fix

Component	US-owned default	EU-owned alternative	Effort
DNS	Route 53	deSEC / EU-hosted BIND	Low, 2-4 hrs
CDN	CloudFront	Bunny CDN (EU entity)	Medium, 1-2 days
Email	SES / SendGrid	Mailjet (FR entity)	Medium, 1 day + DNS propagation
Object storage	S3	OVHcloud Object Storage / self-hosted MinIO	High, 3-5 days
Monitoring/APM	Datadog	Self-hosted Grafana + Prometheus	High, 1-2 weeks

Notice the pattern: cheap fixes first, expensive fixes require real migration planning.

The pragmatic order of operations

Swap DNS and CDN first. Cheap, fast, immediately reduces exposure. A few hours to a couple days.
Move transactional email next. Slightly more friction from DNS propagation, still low-risk.
Treat object storage as a proper migration, not a cutover. This one involves real data transfer volume. Plan it with a testing window, not a weekend deploy.
Self-host monitoring last, or accept the risk consciously if it's low priority for your threat model. This is the highest-effort item and often the lowest payoff per hour spent.

Caveats worth knowing

We tested from a single European location. If you've got US or APAC traffic, a fully EU-only stack will add real latency you need to benchmark separately.
Legal classification here is based on published transparency reports and EDPB guidance as of early 2025, not a review of your specific contracts. SCCs, the EU-US Data Privacy Framework, and things like AWS's "Digital Sovereignty Pledge" all interact with this picture in ways a pure infra test can't capture.

Bottom line

FISA 702 reauthorization doesn't change the underlying math, it's been in force since 2008. What's changed is that RFPs from regulated industries now explicitly ask vendors to document their exposure. If you haven't audited your sub-processor chain, that's the actual work here, not swapping your primary cloud region.

Full methodology and extended results: Measuring what FISA 702 reauthorization actually changes for EU SaaS infrastructure

Originally published on binadit.com

How DNS resolution works under the hood: a step by step guide for high availability infrastructure

binadit — Wed, 19 Aug 2026 07:10:37 +0000

DNS resolution: the seven hops nobody thinks about until failover breaks

You push a config change, wait for propagation, and traffic still hits the dead server. Sound familiar? Most DNS incidents come down to not knowing what actually happens between a browser typing a domain and a TCP handshake starting. Let's fix that.

This is a practical walkthrough of the resolution chain, plus the config patterns that turn DNS into an active part of your high availability setup instead of a silent single point of failure.

Assumptions

You control a domain through Cloudflare, Route 53, or similar, with dashboard or API access
You have a Linux box with dig, nslookup, and tcpdump/ngrep available
You know the basics of IP, TCP, and UDP
You're comfortable running commands against a real or disposable test domain

We'll use example.com everywhere below. Swap it for your own.

The resolution chain, hop by hop

1. Browser cache

Before anything hits the network, Chrome checks its own DNS cache:

chrome://net-internals/#dns

If there's a live entry, resolution stops right there. This is why a DNS change can look "stuck" in your own browser even after the TTL has expired everywhere else.

2. OS stub resolver

Next stop is the OS-level resolver, usually systemd-resolved or nscd on Linux:

resolvectl status
resolvectl statistics

It checks /etc/hosts, then its own cache, before forwarding anything upstream.

3. Recursive resolver

No local hit means the query goes to a recursive resolver: your ISP's, or a public one like 1.1.1.1 or 8.8.8.8. This is where +trace becomes your best debugging friend:

dig @1.1.1.1 example.com +trace

4. Root servers

The recursive resolver asks a root server who's authoritative for .com. Roots don't know about example.com, only about the TLD:

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.

5. TLD servers

The TLD server hands back your domain's authoritative nameservers, the ones set at your registrar:

example.com. 172800 IN NS ns1.yourdnsprovider.com.
example.com. 172800 IN NS ns2.yourdnsprovider.com.

6. Authoritative nameserver

Finally, the actual record comes back:

example.com. 300 IN A 203.0.113.42

This is the step that matters for HA: which IP gets returned, how fast it can change, and what happens when that IP goes dark.

Configuring DNS for actual failover

Understanding the chain is step one. Making it work for you is step two.

Drop your TTLs on failover-critical records. A 3600s TTL means an hour-long tail of stale traffic during failover. Use 60-300s instead:

example.com. 60 IN A 203.0.113.42

You'll pay for it in query volume against your authoritative nameservers. Worth it.

Attach health checks. Route 53 and Cloudflare can pull an unhealthy origin out of the response set automatically:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.42"}],
        "HealthCheckId": "abcd1234-healthcheck-id"
      }
    }]
  }'

This is the same mechanism behind a clean zero-downtime migration: DNS shifts traffic instead of forcing a hard cutover.

Return multiple A records. Clients can fall back to a second IP:

example.com. 300 IN A 203.0.113.42
example.com. 300 IN A 203.0.113.43

Fine for stateless services behind a load balancer, but not a real substitute for health-checked failover; clients cache order and don't always retry smartly.

Verifying it actually works

Don't trust the dashboard. Check every layer.

dig example.com +noall +answer
dig example.com @8.8.8.8 +noall +answer
dig example.com @1.1.1.1 +noall +answer

Lower-than-configured TTLs from a resolver mean the change is propagating. Original TTLs mean you're still hitting a cached answer.

Check resolution latency directly:

dig example.com | grep "Query time"

Consistently above 100-150ms? Look at resolver placement or a provider with more edge presence. This happens before the TCP handshake even starts, so it's pure overhead on TTFB.

Simulate failover instead of waiting for an incident to test it for you:

iptables -A INPUT -s <health-check-ip> -j DROP
watch -n 5 'dig example.com +short'

Confirm the response flips to your secondary within the configured TTL, then remove the rule.

Add DNS resolution time to your monitoring as its own metric, separate from full page load. A spike there with stable backend times points straight at a resolver or nameserver problem, not your app.

Pitfalls that keep coming back

Default TTLs. 3600 or 86400 seconds quietly kills any failover plan built on top.
Single nameserver provider. One outage there takes your domain down regardless of server health.
DNSSEC misconfiguration. Broken signing chains fail silently for validating resolvers while looking fine in tools that skip validation.
Testing only from your machine. Your local cache hides what real users see. Always check against multiple public resolvers.
Deep CNAME chains. Each extra hop adds latency and another point of failure.

Understand the seven hops, and DNS stops being a mystery box that occasionally ruins your day.

Full original writeup: How DNS resolution works under the hood

Originally published on binadit.com

TTFB vs full page load: choosing the right metric for your ecommerce infrastructure

binadit — Fri, 14 Aug 2026 07:41:20 +0000

Stop chasing TTFB: it's not the metric that's tanking your conversions

Your TTFB dashboard is green. Your conversion rate is red. If that combination sounds familiar, you're not alone, and you're not chasing the wrong fix by accident, you're chasing it because every tool you use puts TTFB front and center.

Here's the problem: TTFB and full page load metrics answer completely different questions, and treating them as interchangeable wastes engineering time on ecommerce sites where every millisecond on checkout pages has a dollar value attached.

What TTFB actually tells you

TTFB is the clock between the request leaving the browser and the first byte coming back. That window includes:

DNS resolution (if uncached)
TCP/TLS handshake
Server-side work: routing, DB queries, template rendering, cache lookups
Network transit for that first byte

On a warm HTTP/2 or HTTP/3 connection, server processing time dominates this number. Which makes TTFB genuinely useful, but only for one job: telling you when your backend is under load.

TTFB baseline: 180ms
TTFB during flash sale: 900ms

That jump isn't noise. It's your app server, DB, or cache layer running out of headroom before a single byte of HTML goes out. On WooCommerce stacks especially, a TTFB spike during a traffic surge is usually the first hard evidence that your PHP-FPM pool or database is maxed out, well before cart abandonment shows up in analytics.

Where TTFB earns its keep

Catching server-side regressions. A slow query, an N+1 bug, a cold cache: TTFB flags these before users notice anything visually.
Load testing and capacity planning. Watch TTFB climb under simulated load and you know exactly where your app tier breaks.
Splitting backend vs frontend blame. Fast TTFB + slow-feeling page = stop looking at the server, start looking at JS and render-blocking assets.

Where it lies to you

A 100ms TTFB tells you nothing about what happens after that byte lands. The page can still take 6 seconds to become usable because of:

Render-blocking CSS/JS
Images without dimensions causing layout shift
A tag manager script hogging the main thread
Late-loading fonts (hello, flash of invisible text)

And here's the trap most teams miss: if a response is served from a CDN edge cache, TTFB measures the edge, not your origin. Your dashboard can look perfectly healthy while your actual application is quietly degrading, right up until a cache miss exposes it in production.

What full page load metrics tell you instead

LCP, Speed Index, fully-loaded time: these track what the user actually sees and feels. That's why Google leans on LCP and CLS for Core Web Vitals; TTFB alone was a bad predictor of both perceived speed and search ranking.

Strengths:

Correlates with real user experience, not just server response
Surfaces conversion killers directly (a bloated hero image, a blocking checkout script)
Feeds into Core Web Vitals and SEO scoring

Weaknesses:

Noisy. A regressed LCP could be caused by the backend, a new marketing pixel, an unoptimized CMS upload, or a hydration delay in your frontend framework
Lagging indicator. You need waterfall analysis and resource timing to find the actual cause after LCP tanks in prod
Out of infra's hands. You can run flawless high-availability infrastructure and still ship a slow LCP because a third-party payment widget is garbage

The decision framework

Stop asking "is TTFB good." Ask this instead:

if (TTFB_high && LCP_high) {
  fixBackendFirst(); // nothing downstream matters until this is solved
}

if (TTFB_low && LCP_high) {
  profileBrowserWaterfall(); // frontend/third-party problem
}

if (TTFB_high && LCP_low) {
  // rare, but check if LCP measurement is misleading you
}

if (servingMostlyFromCDN) {
  trackOriginResponseTimeSeparately(); // edge TTFB will lie to you
}

Practical ownership split:

Situation	Metric to watch	Who owns it
Debugging capacity/backend regression	TTFB	Backend/infra
Debugging conversion drop or CWV score drop	LCP, Speed Index	Frontend + infra
Prepping for a sale or launch	Both, together	Whole team

For traffic events specifically: TTFB tells you when the servers start straining, LCP tells you whether shoppers are actually feeling it. Alert on both, but don't confuse one for the other, and don't let a green TTFB dashboard talk you out of investigating a real conversion problem.

Full writeup with the complete comparison table and more edge cases: TTFB vs full page load: choosing the right metric for your ecommerce infrastructure

Originally published on binadit.com

Measuring how EuroStack changes the procurement conversation for infrastructure management services

binadit — Wed, 12 Aug 2026 07:12:58 +0000

We ran the numbers on 41 procurement deals to see if EuroStack is real or just RFP theater

If you've touched infrastructure procurement in the last year, you've probably seen "EU sovereignty" or "EuroStack" show up somewhere in the RFP. The question every engineering lead asks: is this actual signal that changes vendor selection, or is it a compliance checkbox that nobody enforces?

We had visibility into 41 procurement processes between January 2023 and September 2025, so instead of guessing, we split the data before and after EuroStack-style criteria showed up explicitly in tender docs and measured what actually shifted.

The setup

We defined "EuroStack criteria" narrowly. It had to include:

EU legal jurisdiction over the operating entity
Data processing location inside the EU/EEA
Disclosure of subcontractor data flows, including support and monitoring tooling

"GDPR compliant" with no operational detail didn't count. That's boilerplate, not a filter.

Sample: 41 contracts, €40k to €2.1M ACV, across SaaS (14), public sector (11), fintech/payments (9), and e-commerce/logistics (7). 19 processes ran before explicit sovereignty language appeared, 22 ran after.

We were not benchmarking server performance here. This is purely procurement mechanics: shortlist size, timelines, contract clauses, final price vs. quote.

What actually moved

Metric                              Before    After
Avg. vendors shortlisted            5.2       3.6
% non-EU hyperscaler-reseller-only  47%       12%
Avg. RFP-to-signature time          11.4wk    7.9wk
% with subcontractor disclosure     21%       86%
% with real data residency SLA      32%       79%
Avg. final value vs. initial quote  +14%      +4%

The timeline tail matters more than the average:

Percentile   Before (wk)   After (wk)
p50          9.5           6.0
p95          24.0          15.5
p99          31.0          19.0

Post-signature scope disputes also dropped hard: 42% of "before" contracts had a change request or renegotiation in the first 6 months, usually over data location or support access. In the "after" group, that fell to 18%.

Why this happens

The shortlist shrinking from 5.2 to 3.6 vendors isn't a loss, it's a filter working correctly. Reseller setups that white-label a US hyperscaler and can't answer "where does support tooling send logs" get cut early instead of surviving three rounds of vague reassurance.

That filtering effect is also why timelines compressed. When the RFP already specifies data residency and subcontractor disclosure, vendors don't need three rounds of clarifying questions. We saw this in our own bid pipeline: RFP-to-proposal time dropped from 9 days to 4 when the tender pre-answered the questions we'd otherwise have to ask ourselves.

The contract value delta is the part people underestimate. Vague sovereignty language at RFP stage doesn't disappear, it just resurfaces post-signature as a change order once someone discovers a gap. Explicit criteria up front push that negotiation into the cheap phase instead of the expensive one.

One more pattern worth flagging: buyers who specified sovereignty criteria were also far more likely to require named engineer contacts instead of ticket-based support (61% vs. 23%). Teams that care about knowing where their data lives also tend to care about knowing who picks up the phone.

Caveats before you cite this

Selection bias: we bid on EU-sovereign contracts, so our "before" sample skews toward processes where we were still invited. Fully non-sovereignty procurement is likely faster and larger in scope than what we captured.
Small sample: 41 deals over 2.5 years shows a trend, not statistical proof. One outlier public-sector tender inflated the before-p99 from 24 to 31 weeks.
No official standard exists yet: "EuroStack criteria" is our own classification. There's no certification scheme to point to as of late 2025.
No cost-per-compute comparison: this says nothing about whether EU infra is cheaper or pricier per server-hour than hyperscaler equivalents. Different question, different analysis.

Takeaway for anyone writing or responding to RFPs

If you're a buyer: specific sovereignty requirements (jurisdiction, data location, subcontractor disclosure) act as a fast, cheap filter that eliminates non-answers early and shrinks your timeline. If you're a vendor: if you can't answer where support tooling sends logs, you're going to keep losing time to vendors who can.

Full methodology and data breakdown in the original article.

Originally published on binadit.com