Platformatic
1.1K posts
@platformatic
The platform bridging the gap between Node.js developers, operators, and wider business. So you can focus on building 🚀
The thing most teams get wrong about thundering herd: they think caching solves it. Caching protects future requests, the ones that arrive after the first response is stored. But the window between cache miss and cached response is completely unprotected. During a launch or a viral moment, hundreds of requests hit the same cold endpoint simultaneously. Everyone goes upstream independently. That window is what deduplication closes. Next Wednesday, @matteocollina and I are joined by @p_insogna (Platformatic Principal Engineer + Node.js TSC member) to break down how gateway deduplication works, leader/waiter model, memory vs Valkey, and the production metrics. Without touching a single line of your app code. Wednesday 8:00 am PT / 5:00 pm CEST → streamyard.com/watch/S5FYVgnV…
This is the default for most Medusa teams: backend, storefront, admin, and image optimizer split across separate repos. Four Docker builds. Four pipelines. Every internal API call burns time and resources crossing the network. 𝐁𝐮𝐭 𝐡𝐞𝐫𝐞’𝐬 𝐭𝐡𝐞 𝐫𝐞𝐚𝐥𝐢𝐭𝐲: 𝐧𝐨𝐧𝐞 𝐨𝐟 𝐭𝐡𝐚𝐭 𝐢𝐬 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐧𝐞𝐜𝐞𝐬𝐬𝐚𝐫𝐲. @platformatic flipped the script. The entire stack runs as a Watt monorepo on Kubernetes: one workspace, one build, one deployment artifact. Server-side requests from Next.js to Medusa stay internal, using thread communication. No network hops. No gateways. Just speed. React is pinned once at the root. The image optimizer reuses the storefront codebase with a config swap. Internal and public URLs live side by side, all in one place. Misconfiguration? Now it’s much harder to get wrong. The multi-repo e-commerce stack is just a default, not a requirement. There’s a better way. How many deployment pipelines are you running right now? And what if you could cut that number in half? blog.platformatic.dev/run-medusa-kub…
Most SSR benchmarks measure average latency. Average latency hides what matters in production. In March @platformatic ran @tan_stack, React Router, and Next.js across Node, PM2, and Watt at 1,000 req/s. Real findings: → TanStack + React Router: 100% success on all runtimes. Watt's edge is tail latency. p(99) 83ms vs Node's 298ms. Median is nearly identical. → PM2 + Nitro (TanStack/Nuxt): 81% success, 2.5s average. Same PM2 works perfectly with Express. Match your cluster mode to your server library. → Next.js: 55% success across all three runtimes. The runtime isn't the problem. The SSR pipeline is. Median looks fine. p(99) tells the real story. blog.platformatic.dev/ssr-framework-…
The AWS ECS autoscaler doesn't know Node.js exists. It watches the CPU. Node.js doesn't choke on CPU; it chokes on event loop saturation. By the time CloudWatch fires, the event loop has been backed up for minutes. Target Tracking: 3 minutes before the alarm fires. Then container pull, health checks, and ALB registration. Link this to 5–7 minutes of degraded service before new capacity arrives. We benchmarked it: 929ms median, 74.76% success rate with Target Tracking because it watches CPU. 20ms median, 99.99% with ICC because it watches ELU instead of CPU and predicts 35 seconds ahead. The metric is the problem. CPU is the wrong signal for an event-loop runtime. blog.platformatic.dev/aws-ecs-autosc…
