标签：#Architecture

Project: https://quven.tv/ Security model: https://quven.tv/security/ For the last 18 months, I have been building Quven, a self-hosted media server for personal movie, TV, and documentary libraries. I started with a seemingly simple goal: let people keep their media on their own hardware while giving them a polished client experience. Playback quickly became the hardest part. A media server does not simply send a video file to a screen. It has to understand the source, the client, the network, and the user's choices, then select a playback path without making any of that complexity feel visible. These are some of the lessons I learned. 1. "Can this file play?" is the wrong question The real question is whether a particular client can play a particular combination of: container; video codec and profile; audio codec and channel layout; subtitle format; resolution, bitrate, and frame rate; HDR format; network conditions. A client might support the video codec but not the audio track. A browser might decode the video but require a different container. Enabling an image-based subtitle can turn an otherwise direct-playable file into a video transcode. Playback compatibility is therefore not a boolean property of a file. It is a negotiation between the source and the active client. 2. Direct play should be the preferred outcome, not a promise Direct play preserves the original file and avoids unnecessary server work. When the client supports the selected combination, it is usually the best path. But forcing direct play at all costs produces a worse experience. A high-bitrate file may technically be supported while still exceeding the available connection. A selected subtitle might require burning into the video. A television may accept a container while rejecting one of its audio formats. The practical hierarchy I settled on is: Direct play when the complete source is compatible. Remux when the streams are compatible but the container is not. Transcode only what must chan

TL;DR I merged several training courses into one monorepo and gave every course the same numbered folder shape : 00-planning → 04-post-training . A _TEMPLATE/ you copy to start the next one, an _ARCHIVED/ you park old stuff in, and a CLAUDE.md that makes the convention machine-readable. The trick that makes it stick: templates use <angle-bracket-slots> , and "done" is a grep that returns nothing. I had course material scattered across repos — planning notes here, marketing copy there, facilitator run-sheets in a third place. Every new course started from a blank page, and I re-invented the folder layout each time. So I collapsed everything into one monorepo with a single rule: every course has the identical shape. The lifecycle, as folders The insight isn't "use folders" — it's that a course has a lifecycle , and numbered folders make that lifecycle the primary axis instead of file type. Plan it, sell it, teach it, run it, follow up. Five stages, always in order: Folder Stage What lives here 00-planning/ Prepare Syllabus (source of truth), specs 01-marketing/ Sell Positioning master + channel assets 02-content/ Teach Modules, one file each 03-delivery/ Run Run-sheet, pre-flight checklist, fallback plan 04-post-training/ Follow up Feedback form, follow-up email, post-mortem The numeric prefix isn't decoration. It forces sort order to match the actual workflow, so the folder listing reads like the process itself. Same reason migration files are timestamped — order is information. <course>/ 00-planning/ -> derives everything below 01-marketing/ 02-content/ 03-delivery/ 04-post-training/ --. post-mortem findings | ^------------------' feed back into 00..03 That loop at the end matters: the post-mortem doesn't sit in a graveyard folder. Its findings flow back into the syllabus, the run-sheet, the marketing. The structure runs the same feedback loop it's supposed to teach. _TEMPLATE/ : a course starts as a copy Starting a new course is one line: cp -r _TEMPLATE my-new-cou

TL;DR: Use per-test coverage data to build a reverse map (file → tests that touch it). Git diff + map lookup = run only relevant tests. 43min → 4min CI time. The Problem Everyone Has Your test suite runs for 45 minutes. You change one file. Should you: Run all 2,000 tests? (Safe but slow) Run tests with matching filenames? (Fast but broken) Manually tag tests? (Gets stale immediately) We tried all three. They all failed. The Insight: Stop Guessing, Start Measuring What if we just measured what each test actually executes? Coverage tools have done this for years: { "src/MyComponent.js" : { "statements" : { "0" : 5 , "1" : 12 , "2" : 0 } } } Key insight: Coverage tools report per test run, not per test file. All we needed: save coverage after each individual test. The Architecture (5 Steps) Step 1: Instrument the Code // Build config (webpack/vite/rollup/etc) export default { plugins : [ process . env . COLLECT_COVERAGE && coveragePlugin ({ include : ' src/**/* ' , exclude : [ ' **/*.test.* ' ] }) ] } Works with: Istanbul (JS), coverage.py (Python), SimpleCov (Ruby), JaCoCo (Java) Step 2: Collect Coverage Per Test // Test framework afterEach hook afterEach ( async () => { const coverage = getCoverageData (); saveCoverage ( `coverage- ${ testName } .json` , coverage ); }); Step 3: Build the Reverse Map const map = {} ; for (const coverageFile of allCoverageFiles()) { const testName = extractTestName(coverageFile); const coverage = JSON.parse(read(coverageFile)); map [ testName ] = [] ; for (const [ sourceFile , data ] of Object.entries(coverage)) { if (wasExecuted(data)) { map [ testName ] .push(sourceFile); } } } Example output: { "tests/user-profile.test.js" : [ "src/components/Profile.jsx" , "src/components/Card.jsx" , "src/utils/formatters.js" ] } The magic: The test told us what it executed. No parsing, no guessing. Step 4: Detect Tests CHANGED = $( git diff origin/main...HEAD --name-only ) TESTS = $( lookupTestsInMap " $CHANGED " ) npm test $TESTS Step 5: Auto-Up

GitHub redesigned GitHub Issues navigation using a client-side architecture that combines caching, predictive prefetching, and service workers to reduce perceived latency. The approach uses IndexedDB, in-memory caching, and background synchronization to serve data faster. GitHub reported instant navigation improvements from 4% to 22%, with latency reductions across multiple navigation By Leela Kumili

Anthropic detailed the containment architectures it uses for Claude across its products. It argues that agent safety depends on placing deterministic limits on an agent’s filesystem, network, and execution environment rather than on permission prompts or safeguards. Most notably, it examines failures at trust boundaries and along permitted egress paths that led Anthropic to revise those designs. By Eran Stiller

Most apps start their access control with something like this: function canEditReportsSummary ( role ) { return [ ' EDITOR ' , ' ADMIN ' ]. includes ( role ); } It works, right up until you have a dozen pages, each with a few sections, each needing independent read/write rules per role. Now you've got dozens of these little arrays scattered across the codebase, and adding a new role means hunting down every single one and hoping you didn't miss any. 0 There's a much simpler model that scales cleanly: a three-level permission tree — page → section → { r, w } - plus one generic function that walks it. No new library, no framework lock-in, just a data structure and ~5 lines of code. The shape of the data Instead of scattering role checks in code, define one permission tree per role . Three levels deep: Page — the top-level feature/route ( dashboard , reports , settings ) Section — a sub-area within that page ( overview , summary , billing ) Action — r (read) or w (write) { "dashboard" : { "overview" : { "r" : true , "w" : false }, "analytics" : { "r" : true , "w" : false } }, "reports" : { "summary" : { "r" : true , "w" : false }, "export" : { "r" : false , "w" : false } }, "settings" : { "general" : { "r" : true , "w" : false }, "billing" : { "r" : false , "w" : false } } } This one blob fully describes what a single role can see and do. Give each role its own tree, e.g. for three common roles: Page Section Viewer Editor Admin dashboard overview r r, w r, w dashboard analytics r r r, w reports summary r r, w r, w reports export – r r, w settings general r r r, w settings billing – – r, w Notice how this reads almost like a spreadsheet a product owner could fill in — that's the point. It's declarative data, not scattered if statements, so non-engineers can review it and engineers don't have to guess what a role does. The generic access-check function Once permissions are just nested objects, checking access is one small, reusable, framework-agnostic function: function

The most dangerous overengineering does not look careless. It looks thoughtful. It has clean interfaces, reusable components, configurable behavior, extension points, and an architecture diagram that makes the system appear ready for anything. Then the next feature arrives. A change that should take one afternoon touches seven layers, breaks three abstractions, and forces the team to understand a framework built for requirements that never appeared. That is what makes overengineering difficult to recognize. It rarely presents itself as unnecessary complexity. It presents itself as responsible engineering. It Usually Begins With a Reasonable Fear Developers do not overengineer because they want to make systems harder. They usually remember an earlier project that became painful. Maybe duplicated business logic spread across several screens. Maybe a component could not support a second use case. Maybe an integration became impossible to replace. Maybe a narrow implementation eventually required an expensive rewrite. The next time a similar problem appears, the team tries to protect itself. What if this feature grows? What if another team needs it? What if product asks for configuration? What if we add more providers? What if the rules change? These are reasonable questions. The problem begins when imagined requirements receive the same architectural weight as real ones. A single approval flow becomes a workflow engine. Two similar components become a universal rendering framework. One pricing exception becomes a configurable rules platform. The team tries to avoid future pain and creates immediate friction instead. The first use case now has to support requirements that do not exist. Developers must understand extension points nobody uses, configuration nobody needs, and interfaces protecting boundaries that have not appeared. Thinking about the future is not the mistake. Building the future before there is evidence is. Reuse Is Expensive Before the Pattern Is Stable

Open a lot of .NET projects and you'll find the repository pattern sitting on top of Entity Framework Core. IProductRepository, GetById, Add, Save, the whole set. Underneath, every method just calls the EF Core DbContext and passes the result straight back. The wrapper adds a name and nothing else. So do you need the repository pattern with EF Core? For most apps, no. EF Core already gives you one. DbSet is a repository. It already does the thing the pattern is for. The reason this keeps happening is that the repository pattern got taught alongside EF, so people assume you need one to use the other. You don't. What the Pattern Was For The repository pattern came before EF Core. It started in a time when data access meant hand-written SQL, SqlCommand, and mapping DataReader rows to objects by hand. Wrapping all of that behind an interface was worth it. It hid a real mess, and it let you swap what was underneath without the rest of the app noticing. EF Core already does that. DbContext is the unit of work. DbSet is the repository. SaveChanges() is the commit. The pattern you're adding is one the tool already gives you. What the Wrapper Actually Does Here's the shape you see in most codebases: public class ProductRepository : IProductRepository { private readonly AppDbContext _db ; public ProductRepository ( AppDbContext db ) => _db = db ; public async Task < Product ?> GetById ( int id ) => await _db . Products . FindAsync ( id ); public async Task < List < Product >> GetAll () => await _db . Products . ToListAsync (); public void Add ( Product product ) => _db . Products . Add ( product ); } Read what each method does. GetById calls FindAsync. GetAll calls ToListAsync. Add calls Add. It's a passthrough. Every line hands the call straight to EF Core and returns whatever comes back. You wrote an interface, a class, and a registration to rename methods that already existed. This is what people mean by a generic repository over EF Core, and it's the most common version y

When people hear about a new project scaffolding tool, one of the first questions they ask is: "Can I choose React Query or TanStack Query?" "What about pnpm instead of Bun?" "Can I use ESLint instead of Biome?" "Can I choose Radix instead of Base UI?" "Can I skip Tailwind?" These are reasonable questions. In fact, I asked myself the same ones while building create-notils . My first instinct was to make everything configurable. The more I thought about it, the more I realized I was about to build something I didn't actually want to use. The Configuration Trap Most project generators start simple. Then someone requests another option. Another package manager. Another ORM. Another authentication provider. Another CSS framework. Another UI library. Eventually the CLI starts looking like this: ? Which package manager? ❯ npm pnpm yarn bun ? Which CSS framework? ? Which ORM? ? Which auth library? ? Which formatter? ? Which icon library? ? Which deployment target? It feels flexible. But every new option creates more combinations to support. Five choices in one prompt don't create five possible projects. They multiply with every other prompt. The complexity grows much faster than the number of features. I Built the Tool I Wanted to Use One thing I've learned from building side projects is this: the first user should always be yourself. Every project I start today uses almost exactly the same stack: Next.js 16 React 19 Bun Tailwind CSS v4 shadcn/ui Base UI Biome TypeScript Turborepo (when needed) I wasn't switching between ten different combinations every week. I was rebuilding the same foundation over and over. So instead of asking twenty questions during scaffolding, I decided to optimize for the workflow I actually have. npx create-notils my-app A few seconds later, I'm writing features instead of answering prompts. Opinionated Doesn't Mean Closed There's an important distinction between opinionated and restrictive . Some tools hide their implementation behind abstraction

A birth-chart form looks simple: ask for a date, time, and place, then calculate. The interface may be simple. The input is not. 1992-11-01 01:30 does not identify one universal instant. It is a wall-clock reading that only becomes meaningful after you resolve the place, the historical time-zone rule, and any daylight-saving transition. If the time is unknown, inventing a convenient default can create chart features that were never supported by the user’s data. I ran into these problems while building AstroZen , a Next.js application that calculates a BaZi Four Pillars chart and a Western natal chart before generating an optional interpretation. The most important architectural decision was this: Calculation is an evidence pipeline. Interpretation is a separate layer. This post explains the calculation pipeline, the failure modes I had to remove, and why “unknown” must remain unknown. 1. A city name is not a coordinate Early prototypes often use a short city list or a default coordinate. That works for a layout demo, but it is not acceptable once location affects the result. Names are ambiguous: Paris can mean France or Texas. Springfield needs a state or region. Country abbreviations come in several forms. A valid city must resolve to both coordinates and a time-zone identifier. AstroZen sends the submitted city to Open-Meteo’s geocoding service, then scores the returned candidates against the requested country and optional region hint. It keeps the following structured result: type ResolvedPlace = { name : string ; region : string | null ; country : string ; countryCode : string ; latitude : number ; longitude : number ; timeZone : string ; // IANA, for example "Europe/Madrid" }; Candidate selection considers exact city-name matches, country matches, an optional region hint, and population as a small tie-breaker. Population never replaces the country check. The more important rule is what happens when resolution fails: if ( ! selected || ! countryMatches ( selecte

Most agent tutorials stop at tools: give the model a function schema, hope it calls the right one. That works for get_time and hash_string . It falls apart when the model skips a knowledge search and opens a ticket, or when eighty APIs all land in one context window. Solon AI keeps tools as the execution unit, then adds Talent as the product unit: tools plus SOP plus activation rules. Think of it this way: Tool ≈ a function Talent ≈ a class that owns those functions, their playbook, and when they appear This post is a practical map of when to stay on tools, when to wrap them in a talent, and how registration actually works in Solon v4.0.3. The product failure behind “just add more tools” Bare tools only answer two questions for the model: what can I call? what args does it need? They do not answer: should this capability even be visible right now? what order must I follow before a dangerous call? which tools belong to the same business domain? That gap shows up as: premature side effects (ticket created before diagnosis) context blow-up (full tool tables on every turn) weak SOP compliance (model freestyles across domains) Talent is Solon’s answer: a reusable package of awareness + instruction + tools , with automatic coloring so tools keep their domain identity. Tool vs Talent in one table From the official comparison: Dimension Tool ( FunctionTool ) Talent ( Talent ) Unit Single function / method Instruction + tool set + state Abstraction Physical: how Logical: when and under which SOP Context awareness Passive isSupported(Prompt) can activate or hide Injected content Tool schema (JSON) System prompt fragment + tool list Constraint strength Weak — model freestyles from description Strong — SOP via getInstruction Registration defaultToolAdd / toolAdd defaultTalentAdd / talentAdd They are not rivals. A talent contains tools. Registering a talent also registers its tools; you do not need a second defaultToolAdd for the same set. Lifecycle: what actually runs at reques

Durante anos fizemos a pergunta errada "Será que a IA vai substituir os desenvolvedores?" Hoje sabemos que essa não era a pergunta correta. A pergunta correta é: O que passa a ter valor quando escrever código deixa de ser caro? Isso muda completamente a engenharia de software. Por décadas, metodologias como Waterfall, Scrum, XP, DDD e Clean Architecture nasceram em um mundo onde escrever código era caro. Documentação envelhecia rapidamente porque reescrevê-la custava caro. Especificações eram abandonadas porque implementar consumia semanas. Então surgiu a IA. Pela primeira vez na história, produzir código ficou quase gratuito. O valor migrou. Código ficou barato. Julgamento não. Hoje qualquer LLM produz centenas de linhas de código em segundos. Mas ela não decide: qual problema resolver; quais regras de negócio existem; quais exceções importam; quais compromissos arquiteturais devem permanecer pelos próximos cinco anos. Essas continuam sendo responsabilidades humanas. O gargalo mudou Antes, escrevíamos código. Agora escrevemos decisões. Especificações. Arquiteturas. Critérios de aceitação. Revisões. A vantagem competitiva deixou de ser velocidade de digitação. Passou a ser clareza de pensamento. Por que o vibe coding não escala Conversas são uma péssima fonte de verdade. Cada prompt aumenta o contexto. Cada correção adiciona mais tokens. Cada interação obriga a IA a reconstruir sua intenção. Em algum momento ela deixa de raciocinar sobre o sistema e passa a raciocinar sobre a conversa. Esse é o verdadeiro custo escondido do vibe coding. Especificações passam a ser o centro do projeto Foi essa percepção que originou o Spec Driven Development . A ideia é simples: A conversa deixa de ser a memória do projeto. A especificação passa a ser. Cada funcionalidade nasce de uma spec, evolui para um plano, transforma-se em tarefas e somente depois é implementada. O resultado é previsibilidade. Menos retrabalho. Menos tokens. Menos ambiguidades. https://books.kodel.com.br/pt-br/

In the ever-evolving landscape of technology, software engineers continually seek optimal solutions to complex problems. To achieve this, a deep understanding of the underlying technologies is essential. When considering adopting new technologies, it's crucial to ask: Why : What problem does this technology solve? How does it align with our project's goals? What : What specific tools or frameworks can address our needs? How do they compare in terms of features, performance, and community support? How : How does the technology work? Understanding its inner workings can significantly enhance problem-solving and troubleshooting capabilities. The Benefits of Understanding Technology's Building Blocks Enhanced Problem-Solving : A deep understanding of a technology's fundamentals empowers developers to diagnose and resolve issues more efficiently. Effective Integration : Knowledge of a technology's architecture facilitates seamless integration with existing systems. Optimal Utilization : By grasping a technology's capabilities, developers can leverage its features to their full potential. Future-Proofing : A solid foundation in technology principles enables developers to adapt to emerging trends and innovations. A Case Study: Containers Containers, a popular virtualization technology, provide isolation and portability for applications. By understanding the underlying concepts of namespaces, control groups, CRI, and the Linux kernel, developers can effectively manage and troubleshoot containerized environments. In conclusion, the fast-paced world of software development, staying ahead requires a proactive approach to technology adoption. By carefully considering the "why," "what," and "how" of new technologies, software engineers can make informed decisions, optimize their projects, and deliver innovative solutions.

Building a Decompiler Pipeline in Rust: Why Fission Separates NIR and HIR Decompiler output often looks simple from the outside. A binary goes in. Pseudocode comes out. But between those two points, a decompiler must recover several different kinds of information: instruction semantics register and memory effects control flow stack variables calling conventions data types expressions loops and conditionals readable source-like structure Trying to represent all of this in one intermediate representation quickly becomes difficult. While building Fission , a reverse-engineering and binary decompilation workspace written primarily in Rust, I decided to separate the decompiler pipeline into two main intermediate representations: NIR , a lower-level representation intended to preserve machine semantics HIR , a higher-level representation intended to express recovered, human-readable program structure This article explains why that separation exists, what each representation owns, and why it makes decompiler development easier to reason about. Correctness and readability want different things A decompiler has at least two responsibilities. First, it must preserve the behavior of the original machine code. Second, it must produce output that a human can understand. Those goals overlap, but they are not identical. Consider a simplified fragment of machine-level behavior: tmp0 = RAX tmp1 = tmp0 + 1 RAX = tmp1 flags = update_flags(tmp0, 1, tmp1) A human reader may prefer to see: rax ++ ; The concise form is easier to read, but it omits details that may still matter elsewhere in the pipeline. The flags update could affect a later conditional branch. The operation width may matter. The source and destination could alias. The operation may have originated from an instruction with additional side effects. If the decompiler converts everything into source-like syntax too early, it becomes easy to discard evidence. If it keeps everything at machine level until the final rendering st

AI coding tools have gotten very good at one thing: generating code fast. What they haven't gotten good at is discipline. They don't know your architecture. They don't remember that you rejected a pattern last sprint. They don't know which parts of your context window are signal and which are noise. And they have no concept of a development workflow — no phases, no review gates, no verification steps. You describe what you want, they generate, and you hope the output fits. For small tasks this works fine. For anything that touches your real codebase at scale — refactors, new features with cross-cutting concerns, compliance-sensitive changes — the lack of workflow structure creates subtle, expensive problems that compound over time. We've been building Ortho to address two of these problems: workflow discipline (through ASES, a 6-phase AI development methodology) and context discipline (through a 9-component token optimization pipeline). This post explains both. The workflow problem with AI coding tools When a junior engineer joins your team, you don't just hand them a task and say "generate." There's a process: understand the codebase, plan the change, get the architecture reviewed, build it, test it, verify it, get it reviewed. The process exists because individual steps catch different categories of mistakes. AI coding tools collapse all of that into one step. You prompt. You get code. Done. The result isn't always bad code per file. The problem is architectural: the AI has no model of your layer boundaries, so it imports from layers it shouldn't touch. It has no memory of past decisions, so it re-proposes patterns you've already rejected. It has no verification step, so it confidently generates code that looks right but has subtle issues a reviewer would have caught in 30 seconds. The missing piece isn't a smarter model. It's a workflow. ASES: A 6-phase workflow for AI-assisted development ASES (v1.2) is the methodology built into Ortho's orchestration layer. It

Look closely at what AWS, Microsoft, and Google shipped for AI agents this year and you notice something odd. Different names, different branding, and underneath, the exact same product. That convergence is convenient right up until you try to leave. Here's what they're all building and why it should make you a little cautious. What all three are actually building Strip away the marketing and the three big clouds are assembling the same five-part stack for running enterprise AI agents: a managed runtime to execute the agent, memory so it remembers context, identity so it can authenticate and be governed, tools so it can call your systems, and observability so you can see what it did. The products are AWS Bedrock AgentCore, Microsoft's Azure AI Foundry with its Agent365 control plane, and Google's Vertex AI agent stack. They look different on the pricing page. Architecturally, they're the same idea built three times. This isn't a coincidence. When you're solving the same problem, running agents safely inside an enterprise, you land on the same pieces. The market basically agreed on the shape of an agent platform in early 2026, and each hyperscaler raced to own it on their own cloud. Why the convergence feels great at first If your data and identity already live in one cloud, that cloud's agent runtime is the fastest path to production. Your storage is there, your identity system is there, your logging is there. The platform snaps into all of it. You get governance, audit trails, and deployment almost for free. For a team that just wants agents running with proper controls, that's a real gift. I get the appeal. The catch nobody puts on the slide Here's the trap. When your agent's runtime, credentials, state, and telemetry all live inside one cloud, moving it somewhere else isn't a config change. It's a rebuild. Take AWS Bedrock AgentCore. An agent built on it is wired to AWS identity, networking, and storage. Picking it up and moving it to Azure or Google isn't a matt

Early Access games create a documentation problem that ordinary wikis do not handle well: the facts can change faster than search results, community posts, and copied tables are updated. A page can look polished and still be wrong for the current build. I have been working on an independent Subnautica 2 player wiki, and the most useful engineering lesson has been to treat every guide, map marker, and item row as versioned data rather than timeless prose. This post describes the workflow without assuming any particular framework. 1. Put provenance next to the fact For every structured record, keep at least: the game build or patch it was checked against; the source type: official note, in-game observation, or community report; the observation date; a confidence state such as verified, provisional, or disputed; a stable identifier that survives display-name changes. A user should not have to trust a page because it looks complete. They should be able to see whether a coordinate came from the current build and whether another player can reproduce it. 2. Separate stable identity from mutable labels Names, descriptions, recipes, and locations may change. Use an internal key as the identity and keep display text as versioned attributes. This prevents an item rename from creating a second logical entity or breaking every inbound link. The same rule helps with localization: English and translated labels point to one entity, while the source and verification state remain shared. 3. Model maps as evidence, not decoration An interactive map should not be a pile of pins. A useful marker contains coordinates, category, build, evidence, verification state, and a short player-facing note. If a patch moves or removes the object, preserve the history and mark the old observation as superseded. This also makes filters honest. “Show verified markers for the current build” is a meaningful query; “show everything ever imported” is not. 4. Make guides depend on structured facts Low-spoil

8 min read · telecom provisioning platform, 30M+ subscribers Most companies avoid migrating their monolith for one reason: they imagine it as a single, terrifying event — months of a feature freeze, a weekend cutover, and a rollback plan that's really just hope. That fear is reasonable. A big-bang rewrite of a live system serving 30M+ subscribers really would be terrifying. So we didn't do that. We used a pattern that lets you migrate a monolith one slice at a time, while the system keeps running and the product team keeps shipping features — the same pattern Martin Fowler named Strangler Fig , after the vine that grows around a host tree, gradually taking over, until eventually the original tree is no longer needed. Why the "just rewrite it" instinct is usually wrong The instinct to rewrite a legacy monolith from scratch is understandable — the old code is scary, undocumented, and nobody wants to touch it. But a full rewrite has a well-known failure pattern: it takes far longer than estimated, the business can't freeze feature development for that long, and by the time the rewrite is "done," the old system has changed underneath it and the rewrite is already out of date. The alternative isn't "don't migrate." It's: migrate in slices small enough that each one is boring , and never require the business to stop shipping while you do it. The pattern: a facade, and one slice at a time Strangler Fig works by putting a routing layer — a facade or API gateway — in front of the monolith. At first, 100% of traffic passes through to the old system untouched. Then, one capability at a time: Build the new version of that one capability as an independent service. Update the facade to route just that capability's traffic to the new service. Run both in parallel long enough to trust the new one (see "shadow traffic" below). Retire that piece of the old monolith. Repeat for the next capability. At every point in this process, the system is fully functional. There's no "half-migrat

DoorDash has developed Entity Cache, a transparent proxy caching platform built on Envoy and Valkey to reduce redundant service-to-service requests across its microservices architecture. Operating within DoorDash’s service mesh, the platform serves over 1.5M requests per second with 99.99999% availability through caching, event-driven invalidation, failure handling, and performance optimizations. By Leela Kumili

Perplexity added "Skills" to its Agent API, letting developers compose built-in and custom skills for more complex agent outputs. More skills mean more actions, and more actions mean more ways to produce an irreversible change. Before you add a fifth skill to your agent, make sure the first four have an undo path. The undo problem An agent skill that writes, sends, publishes, or deploys is an irreversible action if there is no rollback. The more skills an agent has, the more irreversible actions it can take in a single session. A chain of skills (research → draft → format → publish) can complete before a human notices the first step was wrong. The undo contract Every agent skill should declare: { "skill_name" : "publish_to_blog" , "action_type" : "write" , "reversible" : true , "undo_method" : "set_published_false" , "undo_timeout_seconds" : 3600 , "undo_side_effects" : [ "SEO index will retain the URL for up to 24h" ] } If reversible is false , the skill should require explicit human approval before execution. A skill registry with undo support # skill_registry.py """ Registers agent skills with undo metadata. Blocks irreversible skills from running without explicit approval. """ from dataclasses import dataclass from typing import Optional , Callable import json @dataclass class Skill : name : str action_type : str # "read", "write", "send", "deploy" reversible : bool undo_fn : Optional [ Callable ] = None undo_timeout_seconds : int = 3600 side_effects : str = "" requires_approval : bool = False class SkillRegistry : def __init__ ( self ): self . skills = {} self . execution_log = [] def register ( self , skill : Skill ): # Irreversible write/send/deploy skills require approval if not skill . reversible and skill . action_type in ( " write " , " send " , " deploy " ): skill . requires_approval = True self . skills [ skill . name ] = skill def execute ( self , skill_name : str , inputs : dict , approved : bool = False ): skill = self . skills . get ( skill_name ) i