标签：#Architecture

Cloudflare released the Cloudflare One stack, an open-source library of agent skills for planning, deploying, and managing Zero Trust environments. The skills include automated migration logic for Zscaler and Palo Alto Networks, the same logic used in Cloudflare's Descaler program that has moved enterprise customers in hours rather than months. By Steef-Jan Wiggers

Building a unified market intelligence platform for traders, analysts, researchers, and developers. After months of development, Jungletrade is now publicly available. The idea behind Jungletrade is simple: modern market analysis has become fragmented. Market data, indicators, analytical models, and trading signals are often distributed across multiple platforms, forcing users to maintain several subscriptions, workflows, and dashboards just to build a complete market view. We wanted to explore a different approach. 📊 The Problem Most market platforms focus on a specific layer of the analytical stack: Raw data Technical indicators Quantitative models Trading signals Each layer provides value, but users are frequently required to move between multiple tools to connect the pieces. Our goal was to create a modular ecosystem where these layers can coexist within a single platform. 🧭 The Jungletrade Ecosystem Today, JungleTrade provides four product categories: 📦 Data Structured datasets for market research and discovery. 🧠 Models Analytical frameworks designed to identify patterns and relationships within market data. 📈 Indicators Tools that transform raw information into actionable insights. ⚡ Triggers Event-driven signals designed to highlight potential market opportunities. 🔍 Built for Transparency One design decision was particularly important to us: every product should explain itself. Each product includes: Product description Key features Use cases Interpretation guidelines Methodology overview The objective is not simply to provide charts but to explain the problem being solved and how the underlying analysis works. 🔌 API First All products available through the platform are also accessible through API endpoints. Developers interested in integrating JungleTrade data into their own applications, dashboards, or research pipelines can request a demo API key through the platform. 🏗️ Architecture JungleTrade is built using a modular, service-oriented architecture des

It is clear that Vyshyvanka is more than just code — it is an ecosystem. The true power of an open-source workflow engine lies in its community. Today, we want to talk about how you can get involved, whether you are interested in pushing the boundaries of the core engine or building specialized solutions with custom plugins. The Core Engine vs. The Plugin Ecosystem A common question we get is: 'Should I contribute a PR to the core engine, or should I build a separate plugin?' The answer depends entirely on the scope of your contribution. When to Contribute to Core The core engine ( Vyshyvanka.Core , Vyshyvanka.Engine , Vyshyvanka.Api , Vyshyvanka.Designer ) should be reserved for changes that benefit every user of the platform. Good candidates for core contributions: Performance improvements to the execution pipeline New fundamental port types or expression functions Bug fixes in the engine, validation, or persistence layers Enhancements to the Designer UI (canvas, node editor, property editors) Improvements to the API surface (new endpoints, better error responses) Documentation improvements These changes require careful review and testing because they impact every installation. We encourage PRs here, but we also ask that you open an issue first so we can discuss the architectural impact. When to Build a Plugin Plugins ( ./plugins/ ) are the best way to extend functionality without increasing the maintenance burden of the core. Good candidates for plugins: Integration with a specific third-party SaaS tool (CRM, CI/CD, monitoring) Custom nodes specific to your industry or use case Experimental node behaviors that are not yet ready for core Proprietary integrations you want to keep separate from the open source project Plugins are independent, versionable, and can be maintained outside the core release cycle. They empower you to solve your specific problems immediately without waiting for a core release. Project Structure at a Glance Understanding where things live i

Slack has outlined how its AI serving infrastructure evolved through four distinct phases, moving from a self-managed Amazon SageMaker deployment to a multi-cloud architecture spanning AWS Bedrock and Google Cloud Vertex AI. By Matt Foster

Why developer tools deserve a design language of their own - and how I built one for my own corner of the web Somewhere along the line, we collectively agreed that "functional" had to mean "boring." Open almost any developer tool, internal dashboard, or technical log and you'll find the same thing: a sterile corporate wiki. Grey on white. The same SaaS design system everyone copied from the same three component libraries. Rounded cards, a sans-serif font, a faint drop shadow. It works. It's also completely forgettable. But here's the thing nobody says out loud: when you're building for engineers - or building your own space on the web - you are under no obligation to follow the standard playbook. The intersection of system design and visual identity is one of the most under-explored areas in frontend architecture. We obsess over latency, bundle size, and runtime dependencies, then slap a default theme on top and call it done. The backend gets all the craft. The interface gets a template. I wanted to do the opposite. Building VOID_PROTOCOL When I put together my own developer log - https://blog.naveenr.in - I deliberately stepped away from the standard minimalist tech blog. Instead, I built out a full design system I call the VOID_PROTOCOL × Manga Editorial Design System: dark-only, type-driven, built on Astro 6, Tailwind 4 (CSS-first @theme tokens), and React 19 islands. The name isn't decoration. VOID_PROTOCOL started on my https://naveenr.in portfolio, which runs in two modes. There's a minimal version, and there's an immersive one - and in immersive mode the background is a real-time 3D simulation of a sentinel entity. It's not a looping video; it actually responds to your movement, clicks, and scroll. When you leave it alone long enough, it sleeps. And when it sleeps, it dreams - it dreams my initials. (Yes, really. It started as a joke and I kept it.) That entity is the soul of the whole identity: black, empty, void-like space and a cool blue palette, a deep-sp

Grab's security team built Palana, a Kubernetes-native secure execution platform, to run autonomous AI agents safely. Unlike deterministic software, model-driven agents exhibit unpredictable tool-use, code-writing, and prompt injection risks. Palana contains these threats at the infrastructure level using isolated namespaces, out-of-process control planes, and proxy-mediated, Vault-backed secrets. By Patrick Farry

Exposing your app to an AI agent over MCP is basically handing someone a master keyring and trusting them to only open the doors they're supposed to. That trust is a bug waiting to happen. This week I wired up a batch of MCP tools over a multi-tenant Laravel app, and the whole exercise was really about one question: how do I let an agent drive the app without letting it drive someone else's data? Here's the thing about MCP tools — each one is an endpoint. An agent calls list_events , publish_event , check_in_participant , and your server runs code on the caller's behalf. The moment you have more than one tenant, every single tool needs to answer two questions before it does anything: are you allowed to do this , and are you allowed to do it *here *. Authorization and scope. Skip either and you've built a confused deputy. The trap: ambient scope doesn't exist under token auth In a normal web request, multi-tenancy is comfortable. You've got a logged-in user, a global scope on the model that quietly appends where organization_id = ? , and you mostly forget it's there. Everything Just Works because there's an ambient "current organization" sitting in the session. MCP tools don't have that. The caller authenticates with a token, there's no session, no middleware stack that set up a current-tenant context. If you lean on a global OrganizationScope that reads "the current org" from somewhere, it reads nothing — and a query you assumed was fenced returns every tenant's rows. That's the kind of bug that doesn't throw an error; it just silently leaks. So the rule I settled on: under token auth, never rely on ambient scope. Filter explicitly, every time, in one place. That "one place" is a small trait every event-scoped tool pulls in: trait ResolvesOrgEvents { protected function resolveOrgEvent ( Authenticatable $user , string $uuid ): ?Event { if ( empty ( $user -> organization_id )) { return null ; } return Event :: query () -> withOrganization ( $user -> organization_id )

Hey Dev Community, If you are running enterprise-scale web scrapers, pricing monitors, or data ingestion pipelines for LLMs, you’ve probably spent sleepless nights dealing with network latency and sudden 403 blocks. When choosing an infrastructure partner, every provider pitches the same script: "99.9% uptime guarantees, millions of residential IPs, and lightning-fast response times." But in the trenches of real-world data collection, we all know that marketing numbers rarely match production reality. Last quarter, my team ran an exhaustive infrastructure audit to compare proxy providers pricing performance and infrastructure stability. If you want to dive straight into our live dataset, telemetry scripts, and interactive monitoring utilities, you can check out the full workbench at ProxyVero . Here is a technical breakdown of how we built our benchmarking matrix, and the architectural gaps we discovered across mainstream enterprise proxy services. 📊 1. The Core Metrics: Uptime vs. Success Rates The biggest lie in the networking industry is confusing Server Uptime with Request Success Rate . A proxy gateway server can maintain a 99.9% uptime while the underlying residential peer network is failing 20% of your data collection requests due to strict target WAFs or high peer churn. When conducting our proxy providers uptime guarantees performance benchmarks , we evaluated three core parameters: TCP Handshake Latency : The time it takes to establish a connection with the proxy endpoint. TTFB (Time to First Byte) : Critical for parsing dynamic JavaScript targets. HTTP Status Code Reliability : Tracking the exact ratio of 200 OK vs. 403 Forbidden / 429 Too Many Requests . ⚖️ 2. The Big Three: Oxylabs vs Bright Data vs SmartProxy Comparison To provide an objective proxy network performance benchmarks comparison , we deployed standard headless browser worker instances (Playwright/Puppeteer) routed through different enterprise gateways. Below is a high-level summary of our a

Thariq Shihipar, engineering lead for the Claude Code team, recently published a blog post (Using Claude Code: The Unreasonable Effectiveness of HTML) arguing that HTML, with its richer visualizations, color, and interactivity, improves the productivity of human-agent communication in many settings, especially when compared to default Markdown outputs. By Bruno Couriol

One universal AI agent sounds convenient. One agent to read tickets, write code, generate tests,...

When designing systems like Facebook, WhatsApp, Netflix, Amazon, or Instagram, one of the first questions a system designer asks is: Can a single server handle the traffic? How much storage will be needed? Do we need caching? How much RAM should our cache have? How many servers should we deploy? Before discussing databases, load balancers, microservices, or caching layers, we need a rough understanding of the scale. This is where Back-of-the-Envelope Calculations come into the picture. Why Do We Need Back-of-the-Envelope Calculations? Imagine you're asked to design Facebook. If you immediately start drawing: Load Balancer ↓ Application Servers ↓ Redis Cache ↓ Database without knowing the expected traffic, you're designing blindly. System design is fundamentally about making trade-offs. To make those trade-offs, we first need estimates. Back-of-the-envelope calculations help us answer: How much traffic will the system receive? How much data will be generated? How much cache memory is required? How many servers are needed? The numbers don't need to be perfect. They only need to be close enough to make architectural decisions. What Exactly Is a Back-of-the-Envelope Calculation? A quick estimation technique used to approximate: Traffic Storage Memory Server Capacity using rough assumptions. Think of it as: "Getting the order of magnitude correct rather than getting the exact number correct." A system designer rarely needs perfect accuracy during interviews. They need reasonable estimates. The Standard Estimation Flow Whenever you get a System Design question: Users ↓ Traffic ↓ Storage ↓ RAM / Cache ↓ Number of Servers ↓ Architecture Design Always estimate first. Design later. The Ultimate Estimation Cheat Sheet Storage Units Unit Value 1 KB 10³ Bytes 1 MB 10⁶ Bytes 1 GB 10⁹ Bytes 1 TB 10¹² Bytes 1 PB 10¹⁵ Bytes Time Units Unit Value 1 Minute 60 Seconds 1 Hour 3600 Seconds 1 Day 86,400 Seconds Common Assumptions Metric Approximation Peak Traffic 3× Average Traffic Active

Technology companies are extending AI beyond code generation into earlier stages of the software lifecycle, including PRD validation, design inputs, and code review. Initiatives from Uber, DoorDash, and Cloudflare highlight a shift toward AI-driven governance layers that evaluate engineering artifacts before implementation while preserving human oversight across the development pipeline. By Leela Kumili

Synchronous billing is easy, and that's the problem — it makes you think all billing is easy. When a request does its work inline, the billable number is in the response by the time you send it. The gateway meters from there — the meter write, retries and all, is its problem, not yours. From your side, synchronous billing is one number in the response. Asynchronous work breaks that. The request submits a job; the work happens later, in a worker; the result comes back through a poll or a callback. And the thing you bill for — characters processed, pages converted — isn't known when the request arrives. It's known when the job finishes . So you can't meter at the edge. The meter has to fire from the completion path. And the real difficulty is firing it exactly once per unit of completed work — because requests, polls, and retries all conspire to make that zero times or many times. This is platform-agnostic. Every submit-process-poll API has it. I'll use the system I run as the example, but the shape is the same anywhere. Three ways metering goes wrong On arrival. Carry the synchronous habit over and you meter when the job is submitted. But you don't know the size yet, so you're forced into a crude flat fee — or you bill for work that hasn't happened and might fail. Wrong unit, wrong time. On retrieval. The subtle one. You wire the meter to fire when the client fetches the result. Now a client who submits a job, lets it run — costing you real money downstream — and never bothers to poll is never billed. You did the work for free. "Completion" is not "the client picked up the result." It's the worker finishing. Without a fixed quantity. Input characters or output characters? Pages before OCR or after? If you haven't decided exactly what you measure and where, invoices drift and customers argue. Decide once; measure there. All three point the same way: meter on measured work-completion, with a fixed definition of the unit. Not on arrival. Not on retrieval. The mechanism:

Long-running workflows look simple when you first build them. Something happens. A few systems exchange data. Everything completes. Done. At least that's the expectation. Reality is very different. The biggest thing I underestimated was time. Not execution time. Elapsed time. Because once workflows start running for hours, days, or continuously, strange things start happening. APIs become temporarily unavailable Data changes halfway through the process Retries arrive much later than expected Someone manually updates a record Another system processes things in a different order Nothing is broken. But everything is slightly different from when the workflow started. Early on, I assumed workflows were transactions. Start. Execute. Finish. Now I think of them as conversations between systems. And conversations can get interrupted. Another thing I underestimated: State changes. You might start processing an order that is "pending". Ten minutes later, another system marks it as "cancelled". An hour later, a retry comes in from an earlier step. If your workflow only thinks about data, weird things happen. Because the world has changed while the process was still running. Long-running workflows also expose assumptions you didn't know you made. Like: this API will always respond quickly data will arrive in order users won't modify records manually retries will happen immediately Those assumptions survive in testing. Production removes them quickly. One thing that changed how I build these systems: I stopped asking: "Will this workflow finish?" And started asking: "What state will the world be in when it finishes?" Because those are two very different questions. Most problems in long-running systems aren't caused by one big failure. They're caused by lots of small changes happening while the workflow is still alive. And if you don't account for that, eventually the workflow finishes successfully and still produces the wrong outcome. This is something we think about constantly

With the Reactive Data Layer Architecture (RDLA), you establish a clear boundary between public data APIs and private, framework-specific data-source implementations. Your presentation layer operates in a purely reactive manner, observing data changes rather than procedurally querying them. RDLA also simplifies testing by encouraging you to program to interfaces and use clean seeding patterns. By Mervyn Anthony

Introduction Every serious backend developer eventually faces the same problem: you need to make multiple changes to a database as part of a single business operation, and you need all of them to succeed or none of them to go through. Partial updates are worse than no updates at all - they leave your data in an inconsistent state that can be nearly impossible to debug in production. This is not a new problem. Enterprise developers have been solving it for decades, and Martin Fowler documented the canonical solution in his 2002 book Patterns of Enterprise Application Architecture : the Unit of Work pattern. In this article we are going to go deep on what Unit of Work is, why it exists, how it works internally, and how to build a clean, production-quality implementation from scratch in Python using only the standard library. By the end you will have a working implementation you can adapt to any project, and a solid understanding of how popular frameworks like SQLAlchemy and Django ORM implement this pattern under the hood. The full source code is available on GitHub: 👉 github.com/diegocastillo12/unit-of-work-python - ## Background: What is the Unit of Work Pattern? The Unit of Work pattern is part of Martin Fowler's catalog of Patterns of Enterprise Application Architecture (PoEAA), a collection of battle-tested solutions for common problems in enterprise software design. Fowler defines it as follows: > "A Unit of Work maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems." Let's unpack that definition carefully. "Maintains a list of objects affected by a business transaction" - this means the Unit of Work acts as a tracker. When your business logic creates a new object, modifies an existing one, or marks one for deletion, it does not immediately write to the database. Instead, it registers the change with the Unit of Work, which keeps an in-memory list of everything that ne

There's a moment in every ambitious AI engineering project where you convince yourself that more agents means more power. I hit that moment early in building my Python orchestration framework — and I spent several painful weeks learning exactly why that intuition is wrong. The seductive pitch: decompose complex tasks into specialized sub-agents, run them in parallel, let them coordinate. What actually happened was a reliability nightmare that taught me more about agentic architecture than any framework documentation ever could. The Problem I Actually Built My Python orchestration system was designed to automate complex, multi-step workflows — the kind that require planning, research, code generation, and validation to happen in a coherent sequence. Early on, I structured it as a web of parallel agents: a planner, several workers, a validator, and a synthesizer, all exchanging structured messages. On paper it was elegant. In practice, it had three failure modes I couldn't engineer away: Context drift. Each agent only saw the slice of information it was handed. The worker writing one module couldn't see what the worker writing another module had decided. By the time the synthesizer tried to combine outputs, I had conflicting assumptions baked into the results — variable names that clashed, patterns that contradicted each other, interfaces that didn't align. Cascading partial failures. When one agent produced ambiguous output, every downstream agent amplified the ambiguity. A planner that returned a slightly underspecified task description produced workers that each interpreted it differently. Nothing failed loudly. Everything just drifted, quietly, until the final output was incoherent. Debugging opacity. When something went wrong in a parallel multi-agent system, tracing the failure was miserable. Was it the planner? One of the workers? The message-passing layer? I'd rebuilt the worst parts of distributed systems debugging inside a single Python process. The Architec

Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article. Hello friends, System design ** and ** Software design are two important topics for tech interviews and two important skills for Software developers. Without knowing how to design a system, you cannot create new software, and it will also be difficult to learn and understand existing software and systems. That's why big tech companies like FAANG/MAANG pay special attention to System design skills and test candidates thoroughly. Earlier, I have shared system design interview questions like API Gateway vs Load Balancer , Horizontal vs Vertical Scaling , Forward proxy vs reverse proxy , and common System design concepts , and in this article, I am going to share with you the best System design books to learn Software design. Whether you are a beginner or an experienced developer, you can read these books, as you will definitely find valuable stuff. I have read them, and even though I have been doing Software development for more than 15 years, I have learned a lot. System design ** is a complex process, and you need to know a lot of stuff to actually design a system that can withstand the test of time in production. Software architecture is another field where you are expected to learn a lot of things. It's simply impossible to become a software architect by reading a few books, but if you have experience and a hunger to learn, then these books can be a gold mine. These books allow you to learn from other people's experiences. You can read these books to find what challenges they face when they design a real-world system like Spotify, Google, or Amazon, and how they overcome. Each story is a journey in itself, and you will learn a thing or two by reading and then relating with your own experience. I love to read books, and they are my primary source of learning, along with online courses nowadays. In this art

A wide day rather than a deep one — four separate threads across a few projects, each with a lesson worth keeping. I'll teach the patterns and keep the specifics generic. The through-line: make the system honest about what it's actually doing — which queries it fires, whether a service is really up, what a tool will do when you call it twice, and in what order a password change should land. The performance thread got big enough that I split it into its own focused post; here's the short version plus the three other threads. Thread 1 — Stop paying for queries you don't use A sustained sweep through an app (and the package behind it) hunting wasted database work. The highlights: Arm an N+1 detector in dev only. A query detector wired in behind an environment check turns invisible lazy-loads into a visible to-do list. Never in production — it's a developer aid, not a runtime guard. Unused eager loads are N+1s in disguise. Index screens love to with(['creator', 'approver']) for columns a redesign later removed. Not a loop, but the same disease: queries you hydrate and throw away. Delete the eager loads with no consumer in the view. Memoize per-request constants. A default-connection resolver and a sidebar unread count were both recomputed on every call. ??= once, reuse for the rest of the request. Collapse a dashboard's stat queries. ~20 count() calls became one grouped query per table, wrapped in a short-lived cache. A dashboard can tolerate being a few seconds stale; trade live-to-the-second for cheap. The meta-lesson: performance at this layer is mostly removal , and you lock it in with a Pest query-count assertion so nobody quietly re-adds an N+1 six months later. Full write-up in the focused post. Thread 2 — Health checks that actually check Here's a trap I keep seeing in "is it up?" tooling: the check verifies the record exists, or that a config row is present, and calls it green. That's not a health check — that's a config check. The service can be configured per

Some days the work spreads across a few projects instead of landing as one big feature. Today was that — three distinct threads, each with a lesson worth keeping. I'll keep things generic and teach the pattern rather than the project, but the through-line is the same: move things that were hardcoded or ephemeral into something you can configure, repeat, and trust. Thread 1 — Make scheduled tasks configurable instead of code-only If you've run a Laravel app for any length of time, you know the scheduler lives in code: routes/console.php or the kernel, a wall of ->daily() , ->everyFiveMinutes() , ->cron(...) . That's fine until the day an operator — not a developer — needs to change when something runs. Then you're shipping a deploy just to nudge a cron expression. Silly. Today's work pulled scheduler configuration into a settings-backed UI. The pattern is worth stealing: instead of the schedule being a literal in code, the code reads its cadence from a settings store, and there's an admin screen to edit it. // Instead of a hardcoded cadence... $schedule -> command ( 'subscriptions:reconcile' ) -> daily (); // ...read it from settings, with a sane default baked in. $schedule -> command ( 'subscriptions:reconcile' ) -> cron ( $this -> schedulerSettings -> reconcileCron ?? '0 2 * * *' ); Two things made this clean. First, a SchedulerSettings object (Spatie's settings pattern) so the values are typed, cached, and migratable — not loose rows you Setting::get('...') by string key. Second, grouping the more user-facing schedules behind their own modal rather than dumping every cron in one giant form. A subscription-related schedule belongs next to subscriptions; a platform schedule belongs in admin. Same data, but organized by who needs to touch it . The edge case to watch: a UI-editable cron is a foot-gun if you let people type nonsense. Validate the expression on save, and always keep a default so a blank setting can never silently disable a job. Thread 2 — A load-testing