标签：#ev

Five independent clients on one free AI server will produce 429s and a thundering herd unless you add a fair queue. We fixed it with a client-side asyncio queue that capped concurrency at two, prioritized interactive work, and dropped 429s from 23 to 0 on a 100-request mixed workload. Disclosure: This article was prepared as part of MonkeyCode's product outreach. What Failed When Five Developers Shared One Server We shared one MonkeyCode free server for code review and refactoring. Each of us ran our own scripts. Nobody coordinated. The first symptom was latency: requests that took two seconds started taking thirty. Then came the 429s. Then came the retries. Retries made everything worse. The server spent more time rejecting requests than answering them. The timeline compressed quickly: Day 1: two developers, no issues Day 3: four developers, latency doubles Day 5: five developers, 429s appear Day 6: retries cause a thundering herd Day 7: the team stops using the server The root cause was not the server. It was the absence of coordination. Five independent clients hammered one endpoint. Each client assumed it was the only user. The server had no way to prioritize. HTTP 429 is the standard “too many requests” signal; we treated it as a retry cue instead of backpressure. That is how a shared free endpoint turns into a retry storm. The deeper problem was architectural. Each of us built a separate integration. Each integration had its own retry logic. Under load those retries multiplied. The server received about five times the intended traffic, not because we needed five times the work, but because five clients were guessing independently. Contrast the two modes we actually ran: Uncoordinated: five scripts, five retry loops, unbounded in-flight calls, no shared view of queue depth. Coordinated: one process, one priority heap, two in-flight calls, explicit rejection when the queue is full. The first mode failed in a week. The second mode is what we shipped. How We Built

In the fast-paced world of software development, every second counts. Seamless tool interaction is not just a convenience; it's the bedrock of high developer productivity . Even seemingly minor hitches, like a non-functional 'copy link' button, can subtly erode efficiency, leading to frustration and lost time. A recent GitHub Community discussion highlighted just such an issue, where a user reported that the 'Copy link' button in Pull Requests (PRs) was consistently failing, specifically when using the Arc browser on macOS. This isn't merely about a broken button; it's a window into the complex interplay between browsers, web APIs, and the essential tools we rely on daily. The Reported Problem: A Month-Long Frustration The original post by vovapyc detailed a persistent problem: the 'Copy link' button in GitHub PRs had been broken for at least a month. The user specified their setup: Arc browser, MacBook Pro M1 Pro, and macOS 26.2. For dev teams, product managers, and delivery leads, a recurring point of friction like this, preventing a quick share of a PR link, represents a tangible drag on workflow. Imagine the cumulative time lost across a team if every developer had to manually copy URLs from the address bar multiple times a day. GitHub's automated response, while a standard and necessary part of their feedback loop, acknowledged the feedback and assured the user that their input would be reviewed. However, it didn't immediately offer a solution or explanation for the bug, leaving the user, and potentially others experiencing similar issues, in limbo. Diagram illustrating the three gates: Secure Context, Document Focus, and User Permission, that must be passed for the Clipboard API to function.## The Expert Insight: It's Likely the Browser, Not GitHub The true insight, and the crux of this discussion, arrived from hoangperry . Their comprehensive breakdown suggested that the issue was almost certainly browser-specific rather than a core GitHub bug. This distincti

Rank tracking tools love to notify you the instant a number changes. We deliberately don't — our drop alert only fires once an app falls 10 spots or more between two measurements. The tempting, wrong version A 1-spot threshold sounds like the more attentive product. In practice it turns every notification channel into noise: App Store search rank has real day-to-day jitter that has nothing to do with anything you did — a competitor's own rank shifting, a re-index, sampling timing. Alert on every 1-spot move and within a week the alert is something people mute, which defeats the entire point of having one. Why 10, specifically 10 spots is large enough to almost never be pure noise and small enough to still catch a real problem while it's still cheap to fix — a keyword field edit, a screenshot swap, a review-response push. Wait for a 30-spot collapse before alerting and you've waited past the point where the fix is simple. The threshold is symmetric: the same 10-spot rule fires on a jump upward, so a keyword field change you made on purpose gets confirmed by the same mechanism that would have warned you if it went the other way. The trade-off we're making explicit This means small real movements — 3 spots, 5 spots — genuinely don't page anyone. That's intentional, not a limitation we're hiding: an alert system tuned to catch everything catches nothing anyone still trusts by week three. A threshold set high enough that every alert is worth opening is worth more than a lower one that trains you to ignore your own notifications. If you're building anything similar — uptime, price, rank, any noisy time series — the question worth asking isn't "how sensitive can I make this," it's "what's the smallest move that's still cheaper to catch early than to catch late." That number is rarely 1. We build Storelift , where this threshold governs both the in-app alert and the rank-drop email.

¿Tu equipo comparte credenciales por Slack? ¿Discuten arquitectura en herramientas que almacenan todo en servidores de terceros? Existe una alternativa que no depende de ninguna nube: NETO . ¿Qué es NETO? NETO es un chat peer-to-peer diseñado para equipos de desarrollo que trabajan en la misma red local. No hay servidores centrales, no hay cuentas, no hay datos saliendo de tu oficina. Abres el navegador, y ya estás comunicándote con tu equipo. ¿Cómo funciona bajo el capó? La arquitectura de NETO combina tres tecnologías clave: mDNS (Multicast DNS): Permite el descubrimiento automático de peers en la red local sin necesidad de configurar servidores DNS ni registrar direcciones manualmente. Tu equipo aparece de forma instantánea. WebRTC: Establece conexiones directas entre navegadores. Los mensajes viajan de punto

A free server is a data boundary decision, not a cost decision. Every prompt you send to a managed endpoint leaves your network. For a coding agent, that means source code, environment variables, and internal architecture notes travel to someone else's infrastructure. The question is not whether the endpoint is trustworthy; the question is whether you can make the boundary explicit. MonkeyCode's free server option is generous in tokens and removes the ops burden of self-hosting. Disclosure: This article was prepared as part of MonkeyCode's product outreach. But generosity does not change the physics of data flow. The moment your agent calls a remote endpoint, the prompt is out of your control. What you can control is what goes into the prompt. This article is a practical guide to building a privacy gate between your agent and a free server. The gate is a local proxy that sanitizes prompts, redacts secrets, and logs every request. It does not make the server trustworthy; it makes your exposure measurable. The threat model Before writing code, define what you are protecting. For most teams, the sensitive material in prompts falls into three categories: hardcoded credentials, proprietary code snippets, and internal names or URLs. Each category has a different risk profile. Credentials are the worst. A leaked API key in a prompt is a direct compromise. Proprietary code is a legal and competitive risk. Internal names are subtler: they reveal architecture and naming conventions that an attacker can use for phishing or targeted attacks. A free server does not automatically read or store your prompts, but you cannot verify that. The boundary you build must assume the server is an untrusted observer. That assumption drives the design. The privacy gate The gate is a small FastAPI service that sits between your agent and the free server. It accepts OpenAI-compatible requests, rewrites them, forwards them, and returns the response. The rewriting step is where the boundary is en

I ship a lot of small products. Browser extensions, little SaaS tools, one game. Most of them live on their own subdomain and do exactly one job. For a long time the worst part of starting a new one wasn't the product. It was billing. Bank verification, ID verification, waiting for approval, recreating the same plans, wiring the same webhooks, testing the same four subscription states. Every single time. I got good at it the way you get good at anything you resent. So I stopped doing it per product and did it once for all of them. Here's the shape that fell out, including the part I had wrong for months. The thing I had wrong Paddle has a list of approved domains. My assumption was that every site taking money had to be on that list, which meant a review round per subdomain, forever. That's not what the list gates. Approved domains gate the Paddle.js checkout overlay running in a browser . That's it. The server side doesn't care: webhook signature verification: not domain gated creating a customer portal session with the API key: not domain gated your own internal endpoints receiving forwarded events: obviously not domain gated Exactly one thing in the whole flow has to happen on an approved domain, and it's the moment the overlay opens. Everything else can live wherever you want. Once I saw that, the design was basically forced. The shape One payment account. One approved domain, the apex. One webhook endpoint, on that apex, for the entire family: Paddle ──webhook──> apex.example.com/api/webhook/paddle │ ├─ verify signature ├─ read custom_data.site └─ route: own event → handle locally other site → forward raw event to that site unknown → 200 and drop it Two rules make this hold up, and both are about what the shared piece refuses to know. The dispatcher does not know a single price ID. It verifies the signature, reads one field, and forwards the raw snake_case event onward. Mapping a price to a plan, granting credits, writing to a subscription table: all of that li

At 2:47 AM, the email lands: "Your free allowance expires in 72 hours. Upgrade to continue." Your demo works. Your eval harness passes. Your CI pipeline is green. And in three days, every one of those things will be a pile of 429s. I've been on both sides of this. I've built on free tiers that disappeared without notice, and I've watched teams scramble to migrate after the fact. The scramble is always the same: nobody knows which config file points at the remote endpoint, nobody remembers the local model weights were never downloaded, and the "quick fix" takes a full day. So I did the thing I should have done months ago. I ran an exit drill. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI development platform that currently offers a free managed server with a 10M-token allowance. The drill below works against any managed endpoint — MonkeyCode's free server is just a convenient target because the same codebase is self-hostable. The drill: 45 minutes, one laptop, zero meetings The goal is brutal and specific: make the application work without the free server, in under an hour, with only the tools already on your machine. I picked a Friday afternoon. I set a timer. I closed Slack. Here's exactly what happened. Minutes 0–5: Inventory the dependency The first step is finding every place your code touches the remote endpoint. Don't grep for the URL — grep for the client library. grep -rn "openai \| anthropic \| chat/completions" --include = "*.py" --include = "*.ts" --include = "*.js" . In my case, the damage was contained: one config file, two modules, and a test fixture that hardcoded the remote URL. The fix was a single environment variable. But knowing that took five minutes of grepping, not thirty seconds of intuition. The lesson: if your endpoint URL lives in more than one file, you've already failed the drill. It should be an environment variable, period. Minutes 5–15: Stand up the local replacement Th

THE BRICK AND THE POST-IT My chemical plant's first vulnerability wasn't a bug, a piece of malware, or a port left open to the internet. It was a brick. In the computer room — the one with a door held open by a brick — I found a sticky note with credentials on it. They weren't even the right credentials for the system I wanted to break into. But they made me think the way whoever wrote them thinks, so I tried the most obvious pair in the world: admin / admin . And I was in. A brick propping open a door that should be locked. A sticky note guarding a password. A factory-default admin/admin. Three layers of security, three layers defeated — not by a genius hacker, but by a student on day one, carrying no tools at all. If that happens in the IT office, it's a problem. When it happens on a factory floor, where that same computer commands real pumps and valves, it's a different planet. The problem: learning OT without a factory I study computer security. Lately I've been drawn to OT — operational technology, the security of factories, power plants and industrial systems. The problem is simple: you can't learn to defend a factory from a book, and nobody will lend you theirs. Then I realized the answer was already inside the question: if you don't have one, you build one. The build: three commands and a lot of patience The lab is called GRFICSv3: an open source project that simulates an entire chemical plant — the PLC, the operator interface, the network, even the server rooms — inside Docker, on a home computer. Three commands and done: curl -O https://raw.githubusercontent.com/Fortiphyd/GRFICSv3/main/docker-compose.yml docker compose pull docker compose up -d "Three commands and done" is the story version. The real version includes my first error, arriving right on schedule at command number two: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock If you hit this — and you will — here's the diagnosis: the Docker daemon is running fi

This is a submission for Weekend Challenge: Generosity Edition. What I Built When I was...

Kubernetes is encouraging developers to take a closer look at KYAML, a stricter dialect of YAML designed to make Kubernetes configuration more explicit, predictable, and less prone to common YAML errors. By Craig Risi

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for...

Microsoft opened GitHub Copilot code review for Azure Repos to all Azure DevOps customers, after acknowledging that many are not ready to migrate to GitHub. Reviews bill per use through the linked Azure subscription and appear in Cost Management 48 hours later. Budgets notify but do not stop reviews, and concurrency caps at five per organization. By Steef-Jan Wiggers

The "frequency healing" corner of the internet runs on faith. Apps ship MP3s labeled "40Hz gamma" and ask you to believe it. I'm a life scientist who builds web tools, and I couldn't ship that. So I built SereneSynth, a browser-based binaural beat and noise generator — and then I built a live spectrum analyzer into the page so anyone can audit the output in their own browser. This is the engineering write-up: the Web Audio graph, the FFT gotcha that almost made me publish wrong numbers, and how I cross-verified everything in Audacity. The honesty constraint first A binaural beat is not a tone in the air. Play 200 Hz into the left ear and 240 Hz into the right, and the listener's superior olivary complex computes the 40 Hz difference. A microphone — or a mono spectrum analyzer — will never show a 40 Hz peak. So the only honest thing a generator can prove is its carriers and its spectral slope. That is exactly what we measure. The synthesis graph Two sine oscillators, hard-panned with StereoPannerNode, summed into a master GainNode, tapped by an AnalyserNode before the destination — the analyzer observes exactly what the headphones receive. Settings that matter: fftSize 16384, smoothingTimeConstant 0.8. The FFT gotcha that almost made me ship garbage My first version used fftSize 1024: one fat bump near 220 Hz instead of two peaks. Bin width = 44100 / 1024 ≈ 43 Hz, and my carriers are 40 Hz apart — same bin, merged. At fftSize 16384 the bin width drops to ≈ 2.7 Hz and the carriers resolve as razor-sharp spikes at 200.0 and 240.0 Hz. Lesson: FFT size is the magnifying glass. If a "frequency proof" doesn't state its FFT size, ask. The widget renders a log axis (20–1000 Hz) because a linear axis wastes 90% of the canvas, and peak detection labels the top bins in the 100–500 Hz range live. Bit-exact, downloadable verification The page also renders 10-second stereo WAVs via OfflineAudioContext (16-bit PCM, 44.1 kHz): same graph, offline render, RIFF encode. No lossy compre

A production postmortem. We shipped browser-side image compression (Rust → WASM + WebGPU), turned on cross-origin isolation for speed, and watched every format crash with compression worker crashed . Here's the root cause and the fix. The setup We built an image compressor that runs 100% in the browser — Rust compiled to WASM for the codec work, WebGPU for the heavy ML passes (background removal, denoise, watermark). No upload, so users' pixels never leave the device. Privacy is the whole selling point. For the multi-threaded code paths we rely on shared memory + atomics , which in the browser requires crossOriginIsolated . So we served the document with: Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin That gives us crossOriginIsolated === true , unlocks SharedArrayBuffer , and lets the *‑threaded WASM builds actually spawn workers. The build uses a nightly toolchain ( nightly-2025-06-01 + -Z build-std ) with: RUSTFLAGS = "--cfg=... +atomics,+bulk-memory --shared-memory --import-memory" and a custom rayon handle pool ( with_turbo_pool ) instead of build_global , so we control worker lifecycle and can abort/self-heal. The incident After flipping COEP to require-corp in production, every format started crashing with the same message: compression worker crashed Not one codec — JPG, PNG, WebP, AVIF, all of them. It was a P0: the core feature was dead for every user. What made it nasty: it only reproduced under real cross-origin isolation . Local dev without COEP was fine. Staging without the header was fine. So the bug hid until it hit production traffic. Root cause The *‑threaded WASM packages spin up nested rayon workers to parallelize the codec. Under COI + COEP require-corp , those nested workers get blocked by Cross-Origin-Resource-Policy / COEP — the spawned worker script is treated as a cross-origin response without the right CORP header, so the browser refuses it. No worker → the rayon pool never initializes → the compression c

A while back I wrote about organizing configuration in Rails . The idea was simple: drop YAML files into config/configurations/ and get namespaced constants like Config::Bot.api_key instead of the clunky Rails.application.config.bot.api_key . It worked well. But every YAML file needed manual wiring: <%= ENV.fetch("BOT_API_KEY", Rails.application.credentials.dig(:bot, :api_key)) %> . For every key. Across every file. Ugh! So I rebuilt it. Same clean Config::Namespace.key API, but now it chains through all three sources automatically. Before (old module’s YAML): # config/bot.yml shared : api_key : <%= ENV.fetch("BOT_API_KEY", Rails.application.credentials.dig(:bot, :api_key)) %> user_agent : " MyAwesomeBot/1.0" timeout : 10 After (new module’s YAML): # config/bot.yml shared : # Config::Bot.api_key is still available and will check environment variables and then check credentials user_agent : " MyAwesomeBot/1.0" timeout : 10 One API. Three sources. No more guessing where a value lives. You can find the full code on GitHub . What follows are the parts I find most interesting. Lazy namespaces with const_missing The old version scanned a directory at boot and called const_set for every YAML file. That works, but it means every namespace is loaded whether you use it or not. This version uses const_missing instead. Reference Config::Bot for the first time and a Namespace object is created lazily: def self . const_missing ( name ) MUTEX . synchronize do @namespaces ||= {} @namespaces [ name ] ||= Namespace . new ( name ) end end The Mutex isn’t there by accident. In threaded environments (Puma, Solid Queue), two threads could hit const_missing simultaneously. Mutex makes sure only one namespace object gets created. The three source chain Each Namespace uses method_missing to resolve a key: def method_missing ( method , ... ) key = method . to_s . delete_suffix ( "!" ) bang = method . to_s . end_with? ( "!" ) environment_key = " #{ @prefix } _ #{ key . upcase } " return @envi

Most free online PDF tools work by uploading your document to a server, processing it there, and sending it back. For a lot of files that's fine. For a signed contract, a payslip, a medical form, or a scanned ID, it's the entire privacy problem: your document now lives on someone else's machine, subject to their logging, retention, and breach exposure. It doesn't have to work that way. A modern browser can split, merge, compress, sign, and even OCR a PDF without the file ever leaving your device — using libraries like pdf-lib , pdf.js , jsPDF and SheetJS that run entirely in JavaScript. How to tell an uploader from a client-side tool You don't have to trust a marketing claim. Two checks settle it: Watch the network. Open your browser's DevTools → Network tab, then run the tool on a file. If you see your file leave in a POST/PUT request, it uploaded. A client-side tool shows no upload of the document itself. Pull the plug. Load the page, then turn off Wi-Fi and try the tool again. A client-side tool keeps working offline. An uploader breaks the moment the network is gone. The honest tools pass both tests. If a site can't work offline, your file is going somewhere. The trade-offs, stated honestly Client-side processing isn't a free lunch, and any tool that pretends it is should make you suspicious: Memory. Very large PDFs are held in browser memory, so there's a ceiling a server wouldn't have. Speed. OCR in WebAssembly is slower than a server GPU. It's private, not fast. Fidelity. Converting PDF → Word transfers the text , not the layout — the same is true of every converter, but a client-side one can't hide it behind a server. Compression limits. A PDF shrinks by downsampling embedded images or rasterizing pages; a small or text-only PDF may not shrink at all, and rasterizing removes selectable text. We built 24 client-side PDF tools on exactly this principle and wrote down where each limit is, rather than papering over them. If you're evaluating any online PDF tool

AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering, spec-driven development, and now AI harness engineering. Underneath all the terminology, though, something genuinely useful is happening. AI can now help with requirements, challenge a PRD, explore UX ideas, reason about architecture, create implementation plans, write code and validate the result. The obvious question is what AI can do. The more interesting question is whether the way we build software is ready for it. The workflow is changing A workflow we've been exploring breaks development into five stages: requirements, refinement, planning, build and validation . The stages themselves aren't new, but AI can now participate in each one. It can take existing product inputs, help clarify the problem, question assumptions, identify gaps in a PRD and then turn a well-defined requirement into a plan and eventually implementation tasks. This puts more emphasis on the quality of the requirements. A human involved in a project might understand what “improve the experience” means because they've had several conversations about it. An agent doesn't have that shared history. It needs the problem, scope, constraints, edge cases and expected outcome to be explicit. That doesn't mean writing enormous specifications; it means using AI to help make the requirements precise before we start building. AI can actually be a useful, slightly annoying reviewer here, asking what happens when something fails, whether a requirement is testable, whether two parts of the document contradict each other and what we haven't considered yet. It can also help compare different versions of a PRD or have one model review another's output, making gaps easier to spot. The important part is that AI is helping us uncover ambiguity, not making the decisions for us. Maybe coding isn't the bottleneck This becomes more interesting when we look at where teams actually spend their time. Complex work can invo

A few months ago I started building [reversemydiabetes.co]a small health platform focused on helping people manage type 2 diabetes through diet and lifestyle changes. I'm not a doctor — I'm a builder — but the project turned into a genuinely interesting technical challenge, and I wanted to share some of what I learned along the way. Why I started this Type 2 diabetes affects a huge number of people, and a lot of the advice online is either paywalled, badly organized, or written in a way that's hard to act on. I wanted to build something simple: a site that gives people practical, easy-to-follow guidance on blood sugar management, diet planning, and day-to-day habits — without needing a login, a subscription, or a medical degree to understand it. The technical side A few decisions shaped how the site turned out: Content structure over cleverness. Early on I over-engineered the information architecture — trying to build dynamic filtering for every possible diet preference. I scrapped most of it. What actually mattered was clear, well-organized static content: a diabetes diet plan page, a blood sugar basics guide, and a meal-planning section. Simple beats clever when the audience isn't tech-savvy. SEO became a first-class concern, not an afterthought. Health content lives or dies on whether people can actually find it. I spent real time on keyword research — things like "diabetes diet plan," "blood sugar levels," and "type 2 diabetes management" — and restructured pages around what people were actually searching for, rather than what sounded good internally. Performance mattered more than I expected. A lot of the target audience is older, on slower connections, or on older devices. I ended up stripping out a bunch of client-side JavaScript I didn't need and leaned on plain HTML/CSS wherever possible. Lighthouse scores went from "fine" to "actually fast," and bounce rate dropped noticeably. Trust signals are a real UX problem for health content. Unlike a SaaS landing pa

Our dataset said the average loan was 2.3 million kroner. The number that actually mattered was 255,000. Both were correct. Only one of them was true. This is a writeup of three ways a dashboard can be arithmetically perfect and still lie, using real figures from an analysis of 1,000 Norwegian debt consolidation applications. If you build reporting for anyone, you have probably shipped at least one of these. 1. Summing a field that contains two different things A debt consolidation loan pays off your expensive credit card debt. It also, if you own property, rolls your existing mortgage into the same new loan. Same column in the database. Same loan_amount . Utterly different meaning. SELECT AVG ( loan_amount ) FROM applications ; -- 2,300,000 That query is right and the answer is useless. Of that 2.3 million, roughly 1.9 million is an existing mortgage being moved from one lender to another. The expensive debt, the part the customer actually has a problem with, averages 255,000 . So the headline figure overstates the thing you care about by a factor of nine. Nothing in the schema warns you. loan_amount is a number, AVG is a function, the result renders fine. The bug is that one column is holding two concepts and only a human who understands the domain will notice. -- what you actually wanted SELECT AVG ( unsecured_debt ) FROM applications ; -- 255,000 If a column can mean two things depending on another column, split it. Every time. 2. Reporting the mean when the distribution has a tail Income in this dataset runs from ordinary salaries up to about five million kroner. A handful of very high earners drag the mean upward: Mean income: ~635,000 Median income: 647,000 for homeowners, 550,000 for renters Look at what happens there. The mean sits between the two medians and describes neither group. Someone reading only the mean concludes the typical applicant earns 635,000. Nobody earns 635,000. It is an artefact. df . groupby ( ' housing ' )[ ' income ' ]. agg ([ ' mean

When building an online game in Unity, the question is often framed as: Should I use Photon, Netcode for GameObjects, FishNet, or Mirror? That question is too small. In 2026, there is still no single networking product that is optimal for every Unity game. The real decision is a stack : transport, netcode, authority model, session management, server hosting, and backend services. For a GameObject-based action game that needs client prediction, Photon Fusion 2.1 is a strong first PoC baseline . If your priorities are Unity Gaming Services, DOTS/ECS, self-hosting, source access, or deterministic simulation, the starting point changes. This article explains how to make that decision in production terms: latency, cheating, reconnection, hosting, bandwidth, operations, and total cost. This article uses official documentation checked on August 31, 2026 as its factual baseline. SDK versions, pricing, licensing, and service availability can change, so re-check them before committing a production project. What I mean by a real-time multiplayer game The target is roughly this class of game: 2–32 players in the same session continuously synchronized players, enemies, projectiles, or interactable objects input latency that directly affects game feel reconnects, host loss, and late joining that must be handled co-op action, FPS/TPS, racing, or competitive action If you only need turn-based play, leaderboards, chat, friends, or asynchronous PvP, you may not need a sophisticated state-synchronization netcode at all. A backend such as Nakama, PlayFab, or Unity Gaming Services may be the more important part of the architecture. Do not treat “networking” as one product A production multiplayer stack has at least five layers. Layer Responsibility Examples Transport Packet delivery, reliability, connection path, secure channel integration Unity Transport, Photon transport, UDP/WebSocket-based transports Netcode Replication, RPCs, input, prediction, interpolation, rollback Fusion, NGO,