标签：#architecture

How many times have you seen a picture of a plane with red dots posted on the internet without context? There's a famous story about a statistician named Abraham Wald and a bunch of WWII bombers. The military looked at the planes coming back from combat, mapped where they were riddled with bullet holes, and decided to add armor there. Wald, being the kind of person who ruins meetings by being right, pointed out the obvious thing nobody wanted to hear: The planes they were looking at came back . The ones hit in the spots with no bullet holes, the engine, the cockpit, were at the bottom of the English Channel, not available for the survey. Reinforce the parts that aren't shot up. That's where the dead planes got hit. I think about this story a lot, mostly while reading those blog posts titled "X Habits That Made Me a 10x Engineer." The entire industry is a returning-plane survey Here is the uncomfortable thing about software engineering wisdom: almost all of it is collected from the planes that came back. Successful companies write blog posts. Successful founders do podcast tours. Successful engineers give conference talks with titles like "Scaling to 100 Million Users with Three People and a Dream." The companies that did the exact same things and died do not have a booth at the conference. They are not on the panel. They are in the channel, with the engines. And yet we keep doing the survey. We stare at the bullet holes on the survivors and go, "Ah, this is where we add armor." "Netflix uses microservices, so we should too" You have eleven users. Three of them are your co-founders, and one is your mom. Netflix runs a globe-spanning streaming empire on hundreds of microservices because they have hundreds of teams, billions in revenue, and problems you will be lucky to have in a decade. You have a Postgres database that is doing just fine, thank you, and a monolith that boots in four seconds. So naturally, you spend the next eight months splitting your perfectly funct

Every engineering team hits this conversation at some point. Someone proposes GraphQL. Someone else says REST is fine. A third person mentions gRPC and half the room goes quiet. The debate usually ends with the most senior person in the room picking what they're most familiar with. That's not a strategy — that's habit. Here's an objective breakdown of all three, when each one wins, and how to actually make the decision for your specific use case. The Core Mental Model Before comparing them, understand what each one is optimizing for: REST optimizes for simplicity and broad compatibility GraphQL optimizes for flexibility and precise data fetching gRPC optimizes for performance and strongly-typed contracts None of them is universally better. Each one is a tradeoff. The right answer depends entirely on who is consuming your API and what they need from it. REST — The Default That Still Wins Most of the Time REST (Representational State Transfer) is not a protocol. It's an architectural style built on HTTP — verbs, URLs, and status codes most developers already understand. Where REST genuinely wins: Public APIs. If external developers are consuming your API, REST is the only reasonable default. The tooling, documentation patterns, and developer familiarity are unmatched. Stripe, Twilio, GitHub — all REST. Simple CRUD services. If your resource model is straightforward, REST maps cleanly to it. No overhead, no learning curve, no ceremony. Browser-native requests. REST over HTTP works directly in the browser without any special client. Fetch it, done. Where REST struggles: Over-fetching and under-fetching. A single REST endpoint returns a fixed shape. Mobile clients that need 3 fields get 40. Separate data needs often require multiple round trips. Versioning overhead. As covered in our previous post — every breaking change forces a versioning decision. This compounds quickly on complex APIs. GraphQL — Powerful, But You Need to Earn It GraphQL is a query language for your A

Not every failure is permanent. This is something I didn't think about before. When something fails in my app, my first thought was something broke, fix it. But when I started learning how distributed systems actually work, I realized that some failures are not really failures. They're just temporary. Network glitch. API timeout. A service that just restarted. Rate limiting kicking in. These are all failures but they last for a very short time window. If your system tries the same operation again after a few seconds, it will probably succeed. So the question is does your system know how to try again? Or does it just give up the first time something goes wrong? That's what retry is. What Retry Actually Does Without a retry system, if a temporary failure happens that's it. The entire operation fails. The user sees an error. The request is gone. With retry, your system automatically attempts the operation again after a failure. The goal is simple recover from temporary failures without the user even knowing something went wrong. This felt obvious to me once I understood it. But building it properly is where it gets interesting. The Configuration: What Each Part Controls When I looked into how retry systems are actually configured, there were more options than I expected. And each one exists for a specific reason. maxAttempts — this defines the maximum number of times the operation can be attempted. You don't want infinite retries. At some point if it keeps failing, it's probably not a temporary problem. exponential backoff — instead of retrying immediately every time, the delay between retries doubles after each failure. First retry after 1 second, second after 2 seconds, third after 4 seconds. This gives the failing service time to recover instead of bombarding it with requests. baseDelay — this is the starting delay used in the exponential backoff. The first wait time before retrying. maxDelay — this caps the maximum delay. Without this, the exponential backoff keeps

Most AI demos work perfectly on a laptop. But production AI systems can become fragile when everything is handled inside one synchronous API call. A user sends a request. The API extracts text. The API chunks the content. The API generates embeddings. The API stores data. The API waits for everything to finish. This may look simple in a demo, but it quickly becomes a problem in real systems. The problem with one giant API call In many AI applications, the API is expected to do too much. For example, in a document processing or RAG pipeline, one request may trigger multiple heavy steps: text extraction chunking embedding generation indexing summarization database updates If all of this happens inside one synchronous request, the API becomes slow and fragile. If one downstream step fails, the complete request may fail. If traffic increases suddenly, the API may become overloaded. This is why event-driven architecture becomes useful for AI workloads. A better approach: API + Kafka + workers Instead of making the API do everything, we can split the workflow into smaller services. The API accepts the request and publishes an event. Background workers consume events and continue the processing asynchronously. A simple flow looks like this: User Request ↓ FastAPI ↓ Kafka / Redpanda Topic ↓ Python Worker ↓ Next Processing Stage In my practical demo, I am using: FastAPI Redpanda Python workers Docker Compose Kafka-compatible messaging Why Redpanda? Redpanda is Kafka-compatible, which makes it useful for local demos and event-driven architecture experiments. It allows us to work with Kafka-style topics, producers, and consumers while keeping the setup simple for development. What this architecture gives us This approach helps with: decoupling services handling bursty workloads moving long-running tasks to background workers improving scalability isolating failures building production-style AI pipelines This pattern is especially useful for AI systems involving: document proce

This is an adapted excerpt from a guide in my AI Knowledge Hub. The full interactive version is linked at the end. Agentic design patterns are named control structures for arranging LLM calls and tools. This post gives you the decision rule for picking one, the exact shape of each pattern, and the cost each adds — so you can match a task to the minimum structure that solves it. Everything here is model-agnostic and grounded in Anthropic's Building Effective Agents and the Claude Agent SDK. Workflow vs. agent: the split that decides everything Anthropic divides all agentic systems into two categories, and the split decides every downstream tradeoff: Category Definition Control lives in Use when Workflow LLMs and tools orchestrated through predefined code paths Your code You can pre-map the decision tree; want accuracy, control, lower cost Agent LLMs dynamically direct their own processes and tool usage , maintaining control over how they accomplish tasks The model Open-ended task where you can't predict the number of steps Every pattern composes one unit: the augmented LLM — an LLM enhanced with retrieval, tools, and memory. It generates its own search queries, selects tools, and decides what to retain. If a single augmented LLM call solves the task, stop — no pattern required. The escalation rule is the whole game: find "the simplest solution possible, and only increasing complexity when needed" — which "might mean not building agentic systems at all." Agentic systems trade latency and cost for better task performance, so only escalate when a specific failure mode forces it. The agent loop: gather → act → verify → repeat For open-ended tasks, every agent runs the same four-beat loop: Gather context — read files, run agentic search ( grep / find / tail to pull relevant slices instead of whole files), or delegate to subagents with isolated context windows. Take action — execute via tools: bash, code generation, file edits, MCP servers. Verify work — check the result b

Anyone who's wired an autonomous agent into email and calendar the traditional way knows the identifier sprawl: an OAuth client ID, a refresh token per user, a Gmail-specific message ID format, a Microsoft Graph calendar ID, and a webhook subscription ID for each — all with different lifetimes, all able to break independently. Half your "integration" code is really identifier bookkeeping. Nylas Agent Accounts collapse all of that into one value. When you create an account (the feature's in beta), the response hands you a grant_id , and that single string is the handle for everything the agent does — mail, calendar, contacts, attachments, and the webhooks reporting on all of them. One ID, the whole surface Every operation addresses the same path family, /v3/grants/{grant_id}/* : POST /v3/grants/{grant_id}/messages/send # send mail GET /v3/grants/{grant_id}/messages # read the inbox GET /v3/grants/{grant_id}/threads/{thread_id} # full conversation GET /v3/grants/{grant_id}/attachments/{id}/download POST /v3/grants/{grant_id}/events # host a meeting POST /v3/grants/{grant_id}/events/{id}/send-rsvp # respond to one GET /v3/grants/{grant_id}/contacts GET /v3/grants/{grant_id}/rule-evaluations # audit trail This isn't an abstraction invented for agents — an Agent Account is literally just another grant, the same primitive used for connected Gmail and Outlook accounts. The supported endpoints reference puts it as "same endpoints, same auth, same payloads." Anything you built for connected accounts works against an agent's grant unchanged. And the resources behind the ID are real: six system folders provisioned automatically ( inbox , sent , drafts , trash , junk , archive ), a primary calendar that speaks standard iCalendar, and outbound messages capped at 40 MB total. Webhooks route by it too The inbound side completes the picture. You subscribe once at the application level, and every notification — message.created , event.updated , message.bounce_detected , and the rest

Week one: a single test mailbox on a trial domain, provisioned by hand from the dashboard. Week twelve: a fleet of agent mailboxes spread across customer domains, each sending real mail with its own quota and reputation. The API calls are the same at both scales — what changes is everything around them: how you provision, how you share configuration, and how you keep one bad sender from pausing the fleet. Here's what the path from one to thousands looks like with Nylas Agent Accounts , which are currently in beta. Provisioning is a loop, not a ceremony There's no OAuth dance to scale around. Creating a mailbox is one POST with "provider": "nylas" — no refresh token, no consent screen — so a fleet provisioner is just iteration: curl --request POST \ --url "https://api.us.nylas.com/v3/connect/custom" \ --header "Authorization: Bearer <NYLAS_API_KEY>" \ --header "Content-Type: application/json" \ --data '{ "provider": "nylas", "workspace_id": "<WORKSPACE_ID>", "settings": { "email": "agent-0042@agents.yourcompany.com" } }' Two scaling-relevant details in that request. First, the domain: one application can manage accounts across any number of registered domains, and the docs explicitly recommend splitting high-volume outbound across multiple domains ( sales-a.yourcompany.com , sales-b.yourcompany.com ) so reputation damage on one doesn't contaminate the rest. Second, the workspace_id : passing it at creation is how each account picks up its configuration, which brings us to the part that makes fleets manageable. Configure workspaces, not grants At fleet scale, per-grant configuration is a non-starter. The model here is indirection: policies and rules attach to workspaces , and every account in a workspace inherits them. One policy object — daily send quota, storage cap, retention windows, spam sensitivity — governs a thousand mailboxes, and updating it updates all of them at once. The recommended carve-up is one workspace per agent archetype: outreach agents get a work

Every Agent Account you create lands in a workspace — the only question is whether you picked it or the platform did: curl --request POST \ --url "https://api.us.nylas.com/v3/connect/custom" \ --header "Authorization: Bearer <NYLAS_API_KEY>" \ --header "Content-Type: application/json" \ --data '{ "provider": "nylas", "workspace_id": "<WORKSPACE_ID>", "settings": { "email": "test@your-application.nylas.email" } }' That top-level workspace_id is optional, and what happens when you omit it is one of the more under-read parts of the Nylas Agent Accounts docs (the feature's in beta, so read with that in mind). Workspaces aren't cosmetic grouping — they're the carrier for every policy limit and mail rule that governs your agents. Getting placement wrong means an agent running with the wrong send quota, the wrong spam settings, or no inbound filtering at all. The placement algorithm When a new account is created, placement resolves in this order: Explicit workspace_id on the request — the account goes exactly where you said. The target workspace must belong to the same application; ownership is validated and mismatches are rejected. Auto-grouping by domain — if a workspace has auto_group enabled and its domain matches the new account's email domain, the account joins it automatically. The default workspace — everything else lands here. That third bucket is the interesting one. What the default workspace actually is Every application gets exactly one default workspace, created and managed by the platform. You can't delete it, and you can only update two of its fields: policy_id and rule_ids . Everything else is managed for you. It's easy to read "default" as "throwaway," but it's better understood as your safety net. Any account you forget to place explicitly — a quick test from the CLI, a provisioning script missing the workspace parameter — inherits whatever the default workspace carries. Which leads to a practical recommendation: attach a conservative baseline policy and

Series Final. The four mechanisms covered across this series — knowledge graph, Auto Review, Self-Healing, Recurrence Prevention — plus the non-engineer-PR application that sits on top of them, all hang off a single conviction: AI isn't something to trust; it's something to design. The 'I don't trust AI to fill in the blanks for me' framing this lives inside isn't doubt about generation quality, but the clear-eyed acceptance that AI has no idea what context wasn't handed to it, and that 'ideal behavior with no spec given' is a fantasy. The starting point goes back to 2025, when I was trying to figure out how to make AI actually understand a large codebase — and ran into walls on both context window scaling (lost in the middle, attention dilution) and learning-based approaches (machine unlearning, destructive interference). GraphRAG + MCP became the way out: hand AI only the facts it needs, when it needs them, so it doesn't have to infer. From code-graph (which I burned two months on and threw away) to the current product-graph (cpg). This piece is the philosophy and the trial-and-error behind the whole series: harnesses confine where hallucinations are allowed to happen, design is translating principles into your own use cases, and Coverage 90% as a solo target breaks the implementation.

I had a write that spanned two physically separate databases. A rename that had to propagate across several tables in one database and a couple of tables in another, and the two had to stay consistent. No distributed transaction coordinator was available to me. So I did the obvious thing: opened a transaction on each, did the work, and committed them one after the other inside a try/catch with rollbacks on both sides. It felt safe. It compiled. It passed tests. Then I drew the failure on a whiteboard, and the safety evaporated. The window that ruins everything Here's the structure, simplified: await using var txA = await dbA . Database . BeginTransactionAsync (); await using var txB = await dbB . Database . BeginTransactionAsync (); await DoWorkOnA ( dbA ); await DoWorkOnB ( dbB ); await txA . CommitAsync (); // <-- succeeds await txB . CommitAsync (); // <-- what if this throws? Two transactions do not make one atomic operation. CommitAsync is a point of no return, and there are two of them. Between the first commit returning and the second one starting, there is a window. If txB fails in that window — the connection drops, the process is killed, the database hiccups — then A is permanently committed and B never happens. Your rollback in the catch block is useless: you can't roll back txA , it's already durable. The two databases now disagree, and nothing in your code will heal that on its own. This is the dual-write problem , and it's not a bug you can fix by being more careful with try/catch. The atomicity you want simply isn't available from two independent commits. Ordering them, nesting them, wrapping them — none of it closes the window, because the window is inherent to having two commit points. Why "it's never failed" isn't reassurance The seductive thing about this pattern is that the window is small, so in practice it almost never triggers. You can run it for a year and never see an inconsistency. That's exactly what makes it dangerous: it trains you to tr

Martin Kleppmann, an associate professor at Cambridge and author of Designing Data-Intensive Applications, discusses the evolution of data systems over the last decade, mainly the shift from monolithic databases to modular building blocks. Kleppmann underlines the importance of moving from cloud-centric data storage systems to decentralised data storage similar to Bluesky’s AT protocol. By Martin Kleppmann

In this article, the author outlines a practical approach to AI governance in the cloud, covering discovery of shadow AI, data classification at creation, IAM-based enforcement, policy-as-code, and operational controls. The article shows how organizations can embed governance into delivery pipelines, balancing security, compliance, and developer productivity without relying on manual processes. By Dave Ward

Most of the code in Quorum was written by directing Claude Code, an AI coding agent. That is not the interesting claim, and on its own it is not even a good one. An agent left to run unsupervised produces fast, plausible, locally-correct code that drifts into an incoherent system. The interesting part is the discipline that turned agent speed into a coherent, correct, multi-region database application. That discipline was an append-only architecture decision log. The failure mode of agent-built software An agent has no memory across sessions. It will happily contradict a decision it "made" yesterday, re-open a question that was settled last week, or quietly drift from the design because the local change in front of it looks fine. Each individual output is reasonable. The aggregate, without governance, is a system where the data model fights the access layer and the third change undoes the first. This is the part people underestimate when they talk about AI coding velocity. Speed without a source of truth does not get you to a good system faster. It gets you to entropy faster. A fast writer with no memory and no sense of consequence is a liability at scale unless something outside the agent supplies the continuity. The decision log Quorum carries a file of numbered architecture decisions, DEC-001 onward, now past two dozen. Each entry has the same shape: the context that forced the decision, the decision itself, references to the prior decisions it refines or interacts with, and a status. Three rules make it work: Append-only. Entries are never edited. A later decision can supersede an earlier one, but it does so as a new numbered entry that references the old one. The history of why the system is shaped the way it is stays intact and readable, including the choices that were later reversed and why. Committed separately from code. The decision and the code that implements it are different commits. The log reads as a clean narrative of intent, independent of the diffs

Every time you tap "Book Ride," a system makes dozens of decisions in under two seconds: Which driver? What route? What's the real ETA? This article breaks down exactly how the dispatch algorithm works — from the greedy approach that fails at scale, to the bipartite graphs, batched matching, and surge pricing mechanics that power Uber, Lyft, Grab, and Gojek today. Why a Greedy Dispatch Algorithm Fails (Closest Driver Problem) The first instinct when designing a matching system is to pair every customer with their nearest driver. However, this Greedy approach causes massive losses at a system-wide scale: Example: 3 riders (R1, R2, R3) and 3 drivers (D1, D2, D3) Greedy Matching (closest driver): R1 ← D1 (ETA 2 mins) ✓ R2 ← D3 (ETA 8 mins) ← D2 was "taken" by R1, even though D2 is closer to R2 R3 ← D2 (ETA 10 mins) ← Terrible outcome Total ETA: 2 + 8 + 10 = 20 minutes Optimal Matching (global optimal): R1 ← D2 (ETA 3 mins) R2 ← D1 (ETA 3 mins) R3 ← D3 (ETA 4 mins) Total ETA: 3 + 3 + 4 = 10 minutes ← 50% better! Uber refers to this problem as Global Optimization — finding an assignment strategy that minimizes the total ETA of the entire system , rather than optimizing just for individual pairs. Bipartite Graph Matching: The Mathematical Foundation (Lyft) Before diving into the systems, it helps to understand the mathematical model that all ride-hailing matching engines share at their core. Lyft formalizes dispatch as a bipartite graph matching problem : Bipartite Graph: Set A (Riders): { R1, R2, R3, R4 } Set B (Drivers): { D1, D2, D3, D4, D5 } Edges: every possible Rider ↔ Driver pair Edge Weight: cost of that match (e.g., ETA, driver rating, distance) Goal: Find a set of edges (a "matching") where: - No rider is matched to more than one driver - No driver is matched to more than one rider - The total cost of all selected edges is minimized This is known as the Minimum Weight Bipartite Matching problem. The classical algorithm for solving it is the Hungarian Algorithm (

Most bad decisions in software engineering aren't made because the engineer chose wrong between two...

Every backend engineer has seen this happen, you build an application on a relational database like MySQL, handling thousands of concurrent transactions effortlessly. Then, the business asks for a real time analytics dashboard. But when you run an aggregation query over historical data, suddenly the database that effortlessly managed live traffic starts thrashing, evicting your working set, and dragging application performance down. This isn't a tuning problem, a missing index, or a badly written query. It’s a fundamental architectural collision. OLTP (Online Transaction Processing) OLTP encompasses nearly every concurrent digital interaction triggered across a distributed system. A user downloading a PDF, a microservice firing an automatic maintenance log, a comment on a social feed these are all transactions. Data engineers rely on OLTP systems (like MySQL or PostgreSQL) to capture these concurrent streams of interactions for creating , updating and deleting records. The Tree Based In-Place Engine To reliably capture massive volumes of transactions without corrupting data or locking up the application, OLTP systems rely on a highly optimized, row oriented architecture built around the B+ Tree. Because they must provide immediate, atomic updates to existing records, transactional databases manage state through a strict sequence of physical tree traversal and in-memory page mutation: The B+ Tree Indexing: When a transaction reads or updates id: 1, the engine traverses a B+ Tree from the root, through the branch nodes, directly to the specific physical leaf node holding that row. This O(\log n) traversal guarantees a fast, isolated point-lookup. It ensures the application always hits the single version of the row without scanning irrelevant data. The Buffer Pool & In-Place Updates: OLTP systems perform in place updates. The database pulls the exact page containing id: 1 from the physical disk into memory (the Buffer Pool). The specific row is mutated directly in RAM

The obsession with centralizing heavy compute on backend servers is a massive bottleneck for both cost and latency. In 2026, as more applications move to the edge, developers are realizing that the user's browser is an incredibly powerful, untapped compute engine. Recently, I challenged myself to build a free live chess game analyzer for my developer utility suite, CipherKit. The traditional architecture for this requires passing FEN strings to a dedicated backend cluster running the Stockfish engine, which introduces network latency and scales operational costs linearly. I wanted to achieve a 100% client-side, zero-latency experience. Here is how I offloaded the heavy lifting entirely to the browser edge. The Architecture: WASM + Web Workers Running a heavy calculation engine directly in JavaScript instantly blocks the main UI thread. To achieve a flawless 60fps UI, I completely decoupled the state from the computation. The UI Thread: Handles strict DOM rendering, board states, and piece animations. The Worker Thread: Instantiates the Stockfish engine via WebAssembly within the browser's memory. When a live game update occurs, the main thread fires a simple FEN payload via worker.postMessage() . The Worker processes the deep-line evaluations (Depth 20+) asynchronously in the background. It then streams the evaluation lines back to the main thread without causing a single micro-freeze. The Result By treating the browser as the edge compute layer, the tool achieves: Zero Server Latency: Bypassing API rate limits and network bottlenecks. $0 Infrastructure Cost: Heavy compute is crowd-sourced to the user's local device. Absolute Privacy: Sensitive payloads never leave the browser. If you want to see this local asynchronous thread management in action, you can test the live analyzer (and inspect the network tab) here: 👉 CipherKit Live Chess Analyzer Are you offloading heavy computations to the client side in your current projects, or are you still relying on traditional

Your procurement agent needs three quotes for a hardware order. The vendor on the other side runs a sales agent that answers pricing questions automatically. Neither team has talked to the other. There's no shared API contract, no agreed-upon protocol, no integration project. The procurement agent just... sends an email. The sales agent replies. A negotiation happens. That works because both agents have something most AI agents don't: a real email address. The interop problem nobody's protocol has solved The industry is busy designing agent-to-agent protocols — schemas for capability discovery, message envelopes, trust handshakes. All of them share a bootstrapping problem: both sides have to adopt the same spec, and specs only help once everyone you want to talk to has implemented them. Email skipped that problem decades ago. It's federated (anyone can run a mailbox on any domain), it has identity built in (the address), it has conversation state built in (threading), and every organization on earth already accepts inbound delivery. An agent that speaks SMTP can communicate with any counterpart — human or machine — without anyone agreeing on anything in advance. What each agent needs: a first-class identity Agent Accounts — a beta feature from Nylas — give an agent exactly that. Each one is a hosted mailbox like procurement-agent@yourcompany.com that sends, receives, maintains folders, and is indistinguishable from a human-operated account to anyone interacting with it over SMTP. Under the hood it's just another grant: you get a grant_id that works with the existing Messages, Drafts, Threads, Folders, Attachments, and Webhooks endpoints. The "indistinguishable from a human account" part matters more than it sounds. It means agent-to-agent and agent-to-human are the same code path. Your procurement agent doesn't care whether sales@vendor.example is a person, a bot, or a person who hands hard questions to a bot. The conversation degrades gracefully to human handling a

The most effective safety control for an email agent isn't a better model, a longer system prompt, or a stricter eval suite. It's a draft folder. Here's the setup. Nylas Agent Accounts — currently in beta — are hosted mailboxes your application creates and controls entirely through the API. Each one is a real address with a grant_id that works against the existing Messages, Drafts, Threads, and Folders endpoints, and each mailbox ships with six system folders: inbox , sent , drafts , trash , junk , and archive . That drafts folder is where your approval workflow lives. Full autonomy is a choice, not a default A common pattern for support mailboxes: an LLM drafts replies to common questions, and humans approve the sensitive ones via a webhook flow. The agent handles the boring 80% on its own — password reset instructions, shipping status, "where's the invoice" — and anything touching refunds, legal language, or an angry customer goes through a person first. The threat you're mitigating is mundane: a model that's confidently wrong. Hallucinated discounts, replies to the wrong thread, a tone-deaf response to a complaint. None of these are exotic attacks. They're the everyday failure modes of putting a probabilistic system on an outbound channel, and the mitigation is to put a deterministic gate between "the model wrote something" and "a customer received it." The gate is three API calls The flow: a message.created webhook fires when mail arrives, your classifier decides the risk level, and high-risk replies become drafts instead of sends. Drafts support full CRUD at /v3/grants/{grant_id}/drafts , so the agent creates one like this: curl --request POST \ --url "https://api.us.nylas.com/v3/grants/ $GRANT_ID /drafts" \ --header "Authorization: Bearer $NYLAS_API_KEY " \ --header "Content-Type: application/json" \ --data '{ "subject": "Re: Refund request for order 4821", "body": "Hi Sam, I have processed the refund...", "to": [{ "email": "sam@example.com" }], "reply_to_mess

If you're building a modern data stack that requires either high-throughput transaction processing or large-scale analytical workloads, you've likely come across both Vertica and VoltDB (now rebranded as Volt Active Data). While both are distributed relational database management systems (RDBMS), they are architected for completely opposite use cases — choosing the wrong one can lead to 10x higher costs, missed latency SLAs, and poor application performance. In this guide, we break down every key difference between OpenText Vertica and Volt Active Data, with practical examples, real-world use cases, and best practices to help you make the right choice for your team. Table of Contents What is OpenText Vertica? What is Volt Active Data (Formerly VoltDB)? Core Differences Between Vertica and VoltDB Real-World Use Cases: When to Pick Which Best Practices & Common Mistakes Conclusion & Key Takeaways References What is OpenText Vertica? OpenText Vertica (formerly Micro Focus Vertica) is a columnar relational DBMS built exclusively for analytical (OLAP) workloads, first launched in 2005. As of 2026, the latest stable version is 26.1, with native lakehouse and Apache Iceberg export support for modern data ecosystems. Core Vertica Architecture Vertica's design is optimized for fast queries across massive datasets: Columnar storage : Data is stored by column instead of row, enabling significantly higher compression ratios and faster aggregation queries that only access a small subset of columns Massively Parallel Processing (MPP) : Query execution and data are distributed across hundreds of nodes for parallel processing Dual deployment modes : Enterprise Mode : Shared-nothing architecture with data stored locally on nodes for maximum performance Eon Mode : Compute and storage separated, using shared object storage (S3, GCS, ADLS) to scale compute independently of storage for cloud workloads Projections : Physical, sorted copies of data optimized for common query patterns (ins