Forem

Your Node.js Server is Using Just One CPU. Here's How to Fix It.

Blackwatch — Sun, 24 May 2026 06:10:34 +0000

CLUSTERING

You created your node application, it's ready, you have chosen an 8 vCPU instance to deploy it. You are done with deployment. Everything is working fine, but unknowingly you aren't using the full potential of the deployment. We know that node.js runs on a SINGLE THREAD, which means our node application uses only one vCPU at a time — but you took an 8 vCPU instance, so aren't the other 7 vCPUs sitting there idle?

The solution for this is CLUSTERING. It's a concept of running multiple instances of an application, where each works as an individual entity but still gets the work done and runs on the same port. Now the question is — how will this work? Isn't it going to cause issues among the instances? The simple and short answer is no.

HOW IT WORKS

When clustering is done, we end up with multiple processes. There are two kinds:

Primary – There is only one primary. It is responsible for spinning up the worker processes, managing them, and if any one of them dies, spawning it back. The primary is there only to manage — it doesn't run the code (connecting with db, spinning up server, etc.) Note – If the primary is down, the entire cluster will crash.
Workers – These are the actual instances where the application runs — they serve the users.

Key Facts

Since there are 8 vCPUs in our case, there will be 9 total processes — 1 primary + 8 workers.
Each worker has its own memory – nothing is shared among workers.
Workers share a single port – connections are distributed across them.
Primary is intentionally dumb – never runs code or connects with db.
Workers can't see their siblings — for each worker, only itself exists.

CODE SNIPPET

import cluster from "node:cluster";
import os from "node:os";
import app from "./src/app";
import { connectDB } from "./src/config/database";
import { createServer } from "http";

const PORT = process.env.PORT || 3000;
const enableCluster = process.env.NODE_ENV === "development";

if (enableCluster && cluster.isPrimary) {
  const numWorkers = os.cpus().length;
  for (let i = 0; i < numWorkers; i++) cluster.fork();

  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — respawning`);
    cluster.fork();
  });
} else {
  const httpServer = createServer(app);
  connectDB().then(() => httpServer.listen(PORT));
}

EXPLANATION OF CODE
In production we generally use services like pm2 to manage clustering, but here we are doing it using native options. For that, we first need the cluster and os modules of node.
Then we check if the current process is the primary or not. If it is the primary, we spawn new workers as per the number of cores available — it's not hard coded, we may change it as per our convenience, but it should not be more than the number of cores/vCPUs. If it isn't the primary (meaning we are already inside a worker), we run the actual backend code — connecting to the DB and starting the server. So now we have 8 worker instances up and running (plus the primary watching over them).
Using process.pid, we can see the unique id of each worker.
Note – this id, and whatever happens inside an instance, stays there only. Other instances can't access this one's data, process, etc.

PROS/CONS

Pros:

Uses all CPU cores
Crash isolation
Built into Node
Higher throughput, CPU-bound work
Auto-respawns dead workers

Cons:

Each worker has its own RAM (no shared state)
In-memory caches/sessions break silently
WebSockets/SSE need extra infrastructure
Harder to debug – 'which worker logged that?'
Primary crash = whole cluster dies

Note – load balancing is round-robin on Linux; on Windows, the OS decides routing.

BIG CAVEAT

This much is enough for simple clustering or for learning purposes, as long as our app is using stateless data (REST APIs backed by a DB).

In this case, the DB is the source of truth. Workers don't need to know about each other. Any worker can serve any request.

STATEFUL connections (WebSocket)
Prerequisite — knowledge of websockets.

Now things change. Once a connection is established and the HTTP request is upgraded to a WebSocket, the socket connection details (which user is on which socket) are stored in memory, inside that worker. So if User A connects through Worker 1 and User B connects through Worker 2, both are logged in and both users' data is stored in the DB. But the live sockets sit on different workers. Now when A sends a message to B, Worker 1 tries to push it to B's socket — but B's socket lives in Worker 2's memory, not Worker 1's. So the message gets saved to the DB, but real-time delivery to B fails.
Also, workers are standalone, so they can't even talk to each other to ask "do you have this user with you?"
A TCP socket lives inside one process.

STICKY Session
Imagine a user lands on Worker A and creates a socket connection. Details regarding the session are stored in Worker A's memory. Somehow, on the next request, the user is shifted to Worker B. Now the user tries to continue the conversation. The worker checks if this session exists or not, but there is no record of it in Worker B (that detail lives in Worker A). So the interaction fails.

To make it easier to picture, here are two ways to think about it:

Analogy 1 (hotel front desk) — You check into Hotel A. The front desk writes your name against Room 204. Later, you walk into Hotel B and ask for your room key. Hotel B has no idea who you are, because your check-in details only exist at Hotel A's front desk.

Analogy 2 (locker at a station) — You drop your bag at locker #5 in Station A and get a ticket. Later, you go to Station B and try to use the same ticket. Station B has no locker matching that ticket, because the bag is sitting back in Station A.

To mitigate this issue, we need Sticky Sessions. It ensures that a user stays on a single worker only — pinning all of one client's requests to the same worker.

One more thing worth knowing — Socket.IO's connection handshake itself is made of multiple HTTP requests (long-polling fallback) before it upgrades to WebSocket. Without stickiness, those handshake requests can scatter across different workers, and the connection never even establishes. So sticky sessions are needed not just after the user is connected, but during the initial connection itself.

REDIS ADAPTER for SOCKET
Even with stickiness, workers still can't communicate with each other. So User A on Worker 1 has no way to push a message to User B sitting on Worker 2. This is a major issue in applications using sockets or real-time communication. To solve this, we have adapters — one of them is the Redis adapter for Socket.IO. It acts as a coordination layer on pub/sub. With this in place, when Worker 1 emits a message, the adapter publishes that emit to a shared bus (Redis). Every worker is subscribed to this bus, and the worker that actually owns B's socket picks it up and delivers the message locally. Now the application will work just like an application running on a single instance.

STICKY + ADAPTER
The two solve different problems, and you actually need both together.

Sticky sessions make sure a user's requests always land on the same worker, so the connection (and the handshake) never breaks mid-way.
The Redis adapter makes sure that when a worker needs to push a message to a user sitting on a different worker, the message can still reach them through the shared pub/sub bus.

Sticky alone — your user stays connected, but messages between users on different workers still don't reach. Adapter alone — workers can broadcast across each other, but the initial connection itself keeps breaking. Together — your clustered app behaves like a single instance from the user's perspective.

TL;DR
Node is single-threaded. Clustering spawns one worker per core. REST scales for free because the DB is shared. Sockets don't — connections live in one worker's RAM. Fix with sticky sessions (so handshakes complete) plus a pub/sub adapter (so workers can deliver each other's messages).

So this sums up basic clustering in a node.js application.
Thanks for reading.

🚀 Google Antigravity 2.0 Quietly Changes What It Means to Be a Software Engineer

Nizzad — Sun, 24 May 2026 06:08:55 +0000

This is a submission for the Google I/O 2026 Writing Challenge

Google Antigravity 2.0 Quietly Changes What It Means to Be a Software Engineer

The most important lesson from Google I/O 2026 isn't that AI writes more code. It's that developers are being asked to manage intelligence instead of producing software line by line.

The Day I Realized We Were Asking the Wrong Question
1️⃣ What Google Actually Announced
2️⃣ Why Everyone Is Focusing on the Wrong Thing
3️⃣ The Developer-to-Director Shift
4️⃣ What Makes Antigravity 2.0 Different?
5️⃣ I Tested the New Mental Model
6️⃣ Why Orchestration Matters More Than Velocity
7️⃣ What Legal AI Taught Me About Agents
8️⃣ Risks Nobody Is Talking About Enough
9️⃣ The Competitive Landscape
🔟 Predictions for the Next Three Years
Key Takeaways
Further Reading & References
Conclusion

The Day I Realized We Are Asking the Wrong Question

For the last three years, the dominant conversation around AI-assisted development has revolved around one question:

"How much faster can AI help me write code?"

Google I/O 2026 convinced me we have been asking the wrong question entirely.

After watching the Antigravity 2.0 announcements and spending time understanding the architecture behind them, I came away with a single, clarifying conclusion:

The most important shift is not that AI can write more code. It's that developers are increasingly becoming directors of intelligent systems rather than authors of every implementation detail.

That distinction sounds subtle. I don't think it is.

I believe it represents one of the most significant conceptual changes in software engineering since cloud computing transformed how we think about infrastructure. And it was hiding in plain sight inside what most coverage described as "a new coding tool."

This article explores why — and what it means for anyone building software today.

1️⃣ What Google Actually Announced

At Google I/O 2026, Google introduced Antigravity 2.0 — not as an incremental IDE upgrade, but as a full platform expansion with five surfaces shipped simultaneously.

Surface	What It Does
Antigravity 2.0 Desktop	Standalone app for managing and orchestrating agents - no IDE required
Antigravity CLI (`agy`)	Terminal-native, same agent harness as the desktop, built in Go
Antigravity SDK	Primitives for building custom agents on Google's coding infrastructure
Managed Agents (Gemini API)	Agent orchestration embedded directly into your own applications
Gemini Enterprise Agent Platform	Vertex AI evolved - governance, session memory, centralized controls

The model powering all of it is Gemini 3.5 Flash, which Google claims outperforms Gemini 3.1 Pro on coding benchmarks while running four times faster than competing frontier models.

One detail that deserves its own headline: Gemini 3.5 Flash was co-developed using Antigravity. Google ran the experiment on itself — and the fact that they're willing to say that publicly matters.

On stage, Director of Software Engineering Varun Mohan used Antigravity 2.0's parallel agents to build a working operating system core from scratch — then ran a live Doom clone on top of it — for under $1,000 in compute costs. That demo made headlines. The architecture behind it is more important than the demo itself.

⚠️ Gemini CLI users: Sunset date is June 18, 2026 — 28 days from announcement. Migration is not optional.

2️⃣ Why Everyone Is Focusing on the Wrong Thing

Most coverage of Antigravity 2.0 landed on benchmarks, speed comparisons, and the OS-building demo. All accurate. None of it is the real story.

The first generation of AI coding tools followed a familiar pattern:

Developer writes code → AI suggests → Developer accepts/rejects → Repeat

The developer remained the primary producer. AI acted as an accelerator on a process that was fundamentally unchanged.

Antigravity 2.0 introduces a structurally different loop:

Developer defines goal + constraints
        ↓
Agent spawns specialized subagents
        ↓
Parallel execution across tasks
        ↓
Developer evaluates outputs
        ↓
Developer refines direction

Notice what changed.

The developer is no longer spending primary effort on producing implementation details. The developer spends primary effort on defining objectives, setting constraints, and evaluating outcomes.

The center of gravity moves from writing toward orchestrating.

That shift deserves far more attention than any benchmark chart.

3️⃣ The Developer-to-Director Shift

The phrase that kept coming to mind while studying Antigravity 2.0:

The developer becomes the director.

Directors don't personally operate every camera. They coordinate specialists toward a coherent outcome — defining the vision, allocating responsibilities, evaluating what's working, redirecting what isn't.

Software development with parallel agents increasingly looks the same.

Imagine a feature request:

"Add async payment processing with distributed tracing, rate limiting, and integration tests."

Traditionally: design architecture → write implementation → write tests → instrument observability → perform code review. Sequential. All on you.

With Antigravity 2.0:

// Conceptual Antigravity SDK orchestration
import { AgentOrchestrator } from '@google/antigravity-sdk';

const orchestrator = new AgentOrchestrator({
  model: 'gemini-3.5-flash',
  parallelAgents: 4,
  sandboxed: true, // agents run in isolated Linux environments
});

const result = await orchestrator.run({
  intent: "Add async payment processing with OpenTelemetry tracing and 90%+ test coverage",
  context: {
    codebase: './src/payments',
    constraints: ['no breaking API changes', 'preserve existing error codes']
  },
  subagents: [
    { role: 'refactor',      focus: 'async patterns'         },
    { role: 'observability', focus: 'tracing instrumentation' },
    { role: 'testing',       focus: 'integration test suite'  },
    { role: 'review',        focus: 'cross-agent consistency' }
  ]
});

The four specialized agents execute in parallel. The review subagent checks consistency across the other agents' outputs — a meta-layer of quality control that single-agent systems structurally cannot provide.

4️⃣ What Makes Antigravity 2.0 Different?

Several design decisions stand out as genuinely distinctive rather than marketing language.

One Harness Across All Surfaces

The desktop app, CLI, SDK, and API all share a common orchestration foundation. Developers aren't learning five separate systems. They're learning one mental model expressed through different interfaces. That consistency eliminates a painful class of bugs: the "works in the GUI but fails in the CLI" failure mode that plagues tools with inconsistent backends.

Co-Optimized Model and Harness

Google spent the months between v1 and v2 co-optimizing three layers simultaneously: the product, the agent harness, and the Gemini training stack. The model is trained against the harness it runs inside. That feedback loop is a structural advantage that competitors using third-party models cannot easily replicate — and it's why Google's claim that Gemini 3.5 Flash was built with Antigravity matters beyond the anecdote.

JSON Hooks for Extensibility

A new hooks system lets you intercept and control agent behavior at execution time without modifying the agent itself:

{
  "hooks": {
    "pre_execution": {
      "type": "approval_gate",
      "condition": "file_changes > 50",
      "action": "require_human_approval"
    },
    "post_execution": {
      "type": "audit_log",
      "destination": "compliance_db",
      "fields": ["agent_id", "files_modified", "timestamp", "cost_tokens"]
    }
  }
}

This is what enables compliance checkpoints, custom logging, and approval gates — the features that make enterprise adoption feasible rather than aspirational.

Project Scope Replaces Workspace Scope

Previously, agent conversations were scoped to a single repository. Now they're scoped to a "project" spanning multiple folders, each with independent permission settings. This unlocks genuine cross-repo tasks — refactoring a shared library and its consumers simultaneously — while preserving fine-grained access control.

Honest Admission on Browser Capability

The [/browser](https://antigravity.google/docs/getting-started) command is an explicit opt-in, not a default. The team acknowledged that agents weren't reliably deciding when to use the browser on their own. Rather than ship a system that behaves unpredictably, they made it explicit. That kind of candor is worth noting — it signals a team that prioritizes trustworthy behavior over impressive demos.

5️⃣ I Tested the New Mental Model

Rather than just analyzing announcements, I wanted to stress-test the orchestration premise with a realistic scenario.

I took a moderately complex service — a document processing module handling file intake, classification, and storage — and worked through specifying it for agent execution versus writing it manually.

What I discovered:

The specification problem is harder than it looks. When writing for myself, I hold context in my head and make judgment calls mid-implementation. When specifying for agents, every constraint I didn't write down explicitly became a decision the agent made on its own. My first attempt produced a technically correct result that violated two implicit assumptions I hadn't stated: file size limits and idempotency requirements on retry. The output was plausible. It was also wrong for my specific system.

The lesson landed immediately: the quality of your specification is now the quality of your output.

The /grill-me command is underrated. This slash command makes the agent interrogate you with clarifying questions before writing a single line. I used it on my second attempt. It surfaced three edge cases I hadn't considered. The resulting output required almost no revision. I'd argue this command is more valuable than any benchmark number.

Parallel agents excel at tasks that suffer from context switching. Simultaneous agents handling refactoring, test generation, and documentation — without each one's context polluting the others — produced noticeably cleaner, more coherent outputs than sequential single-agent approaches.

What failed: The review agent caught internal inconsistencies but couldn't catch domain-level errors. It didn't know that "retry on failure" carried specific compliance implications in my context. The agent produces plausible code. Whether it's correct code for your specific system remains your responsibility.

That gap — between plausible and correct — is where the real risk lives, and it won't appear in any benchmark.

6️⃣ Why Orchestration Matters More Than Velocity

For years, software engineering rewarded implementation speed above most other metrics. Orchestration doesn't make velocity irrelevant — but it introduces a different set of skills that are now becoming primary differentiators.

Specification Quality

The difference between "add user authentication" and "implement JWT with refresh tokens, 5-attempt rate limiting, and 24-hour email verification, backward-compatible with v1.x clients" is the difference between a working system and a security incident. Poor requirements create poor agent outcomes, regardless of model capability.

Evaluation Capability

Can you spot the subtle race condition? The SQL injection vulnerability in the parameterized query generated inconsistently? The memory leak in the async handler? Agents produce plausible output. Engineers must become skilled evaluators of outputs they did not personally write.

Architectural Judgment

Agents generate solutions. Choosing the right solution — and understanding why a microservices boundary here creates coupling problems there — remains a human responsibility that agents cannot currently carry.

Constraint Design

Good constraints prevent expensive mistakes before they occur. Anticipating failure modes before agents encounter them is increasingly the highest-leverage engineering skill.

None of these are new. They have always separated exceptional engineers from good ones. What's new is that they are now the primary differentiating skills, and the path to developing them no longer runs automatically through years of syntax practice. That creates a skills development challenge the industry hasn't fully reckoned with.

7️⃣ What Legal AI Taught Me About Agents

My background spans both technology and legal practice. That combination gives me a perspective I rarely see in articles about Antigravity 2.0, and I think it reveals something important about where this platform is actually headed.

Google's announcement explicitly states that Antigravity 2.0 is designed to extend beyond software development into knowledge work broadly. The team acknowledges there is "a ceiling to the overall value we can provide users by accelerating just coding." The platform is deliberately scoped beyond code from day one.

That framing reasons well with everything I've observed in legal AI.

Legal work rarely involves a single isolated task. A typical compliance review requires:

Research Agent      → Locate relevant legislation and regulations
        ↓
Analysis Agent      → Extract applicable legal principles
        ↓
Compliance Agent    → Identify gaps against specific requirements
        ↓
Drafting Agent      → Generate recommendations or advisory memo
        ↓
Human Legal Reviewer → Apply domain judgment and carry accountability

Notice the structural similarity to a software engineering workflow.

The orchestration model is nearly identical. Only the domain specialists differ.

A data protection compliance review under Sri Lanka's PDPA, the UAE PDPL, and GDPR simultaneously — three jurisdictions, three sets of compliance criteria, distinct legal obligations — is exactly the kind of multi-specialist, parallel-reasoning task that agent orchestration is architecturally suited for. The legal reviewer doesn't disappear. They become the director: defining the scope, evaluating the outputs, and carrying the professional accountability.

This is the implication most articles miss: Antigravity 2.0 is not a software development tool that happens to be extensible. It is an orchestration platform that uses software as its most mature proving ground. The architecture is built to generalize.

For developers reading this: the platform you adopt for your coding workflow may soon be what your legal, compliance, and operations teams are running their workflows on. The organizational politics of AI tooling are about to become considerably more interesting.

8️⃣ Risks Nobody Is Talking About Enough

Every transformative technology carries risks proportional to its capability. Agentic development is no exception — and the risks here are more subtle than most coverage acknowledges.

The Overconfidence Problem

Here is the observation I believe matters most, and that I have not seen stated clearly elsewhere:

The biggest risk of agentic development isn't hallucination. It's overconfidence from developers who gradually stop reading code they didn't write.

Hallucination is visible. Plausible-but-wrong is not.

An agent that confidently generates a complete, well-formatted, thoroughly commented implementation of something subtly incorrect is more dangerous than one that produces obvious garbage. The former gets merged. The latter gets rejected immediately.

As agents become more capable, their outputs become more compelling. The temptation to reduce verification effort will grow proportionally. That habit can become catastrophic — and it won't appear in any capability benchmark.

The Hollow Skills Pipeline

Junior developers learn through a specific path: write code, encounter bugs, debug systematically, build diagnostic intuition. If agents handle increasing amounts of implementation, how do future engineers develop the evaluation skills needed to catch agent errors? This is an industry-level challenge with no obvious answer yet.

Auditability at Scale

Organizations deploying agents at scale will face questions they cannot currently answer cleanly:

Which agent made this change?
What context was it operating with?
What tradeoffs did it make implicitly?
What assumptions are embedded in this output?

Transparency will become as important as capability for enterprise adoption — and the tooling for it doesn't yet exist at the required maturity.

Vendor Depth and Exit Cost

The Antigravity SDK ties workflows to Google's agent harness. The deeper the integration, the higher the exit cost. This is a deliberate platform strategy, not an oversight. Teams should model the cost of migration before committing deeply — not after.

9️⃣ The Competitive Landscape: An Honest Assessment

Where Does Antigravity 2.0 Actually Stand?

Platform	Key Strengths	Potential Limitations
Google Antigravity 2.0	Parallel subagents, unified desktop/CLI/SDK ecosystem, enterprise-ready platform, Gemini integration	Vendor lock-in concerns, evaluation tooling still evolving
Claude Code	Exceptional code reasoning, safety-first defaults, strong MCP ecosystem, trusted by many developers	Less emphasis on parallel agent execution
OpenAI Codex + Operator	Browser access, research capabilities, flexible task automation, powerful multimodal workflows	Less structured orchestration model
AWS Kiro	AWS-native IAM integration, specification-first development workflow, enterprise security alignment	Newer ecosystem and smaller community adoption
GitHub Copilot Workspace	Deep GitHub integration, pull request awareness, VS Code native experience	Lower autonomy compared to agent-first platforms
OpenHands (Open Source)	Self-hostable, transparent architecture, no vendor lock-in, governance flexibility	Higher operational overhead and maintenance burden

VS Claude Code (Anthropic): More conservative on autonomy, more rigorous on safety defaults, exceptional code reasoning. The tradeoff is intentional — less parallelism, more predictability. For teams where auditability is the primary constraint, Claude Code's approach may be more appropriate than Antigravity's velocity-first model.

VS OpenAI: Better suited for open-ended research and browser-based UI automation than structured multi-agent orchestration. A different use case more than a direct competitor.

VS AWS Kiro: Strong spec-first workflow with native IAM integration. For teams already committed to AWS infrastructure, Kiro's trust model is a genuine advantage. Antigravity wins on parallelism; Kiro wins on AWS-native security.

VS Open Source (OpenHands): Benchmarking competitively and self-hostable — critical for organizations with data residency requirements. The tradeoff is operational overhead and the absence of managed enterprise governance features.

My Take

No platform dominates every use case.

Antigravity 2.0 currently offers one of the most complete agent-orchestration ecosystems.
Claude Code excels in reasoning quality and safety-focused workflows.
OpenAI's ecosystem is particularly strong for research-heavy and browser-driven tasks.
AWS Kiro is attractive for organizations deeply invested in AWS infrastructure.
GitHub Copilot Workspace fits naturally into existing GitHub-centric engineering processes.
OpenHands and other open-source alternatives appeal to teams prioritizing control, transparency, and deployment flexibility.

The most interesting competition is no longer about who generates the best code completion.

It is increasingly about who provides the best environment for orchestrating, governing, and evaluating intelligent agents at scale.

The honest summary: If Google's ecosystem integration vision succeeds, Antigravity 2.0's moat deepens significantly over time. But that outcome is not guaranteed, the alternatives are serious, and no single platform dominates all use cases. Evaluate against your specific trust model, governance requirements, and ecosystem constraints — not raw benchmark numbers.

🔟 Predictions for the Next Three Years

I offer these not as certainties but as informed observations from someone watching both the technical and governance dimensions of this space closely.

By 2027 → "Agent orchestration" becomes a listed skill in senior engineering job descriptions at technology-forward companies — alongside system design and distributed systems. This transition has already quietly begun.

By 2027 → At least two significant production post-mortems will cite "agent output not reviewed by an engineer with sufficient domain knowledge" as a root cause. This will create a new market for agent audit tooling, and accelerate governance framework development.

By 2028 → Production system architecture visibly reflects agent-generation patterns — more modular, more explicitly documented, more predictable. A counter-movement of "human-authored critical paths" advocates will emerge in regulated industries. Both camps will be right for their contexts.

By 2028 → The orchestration model pioneered in software development appears in legal research platforms, compliance systems, and policy analysis tools — same architectural pattern, different domain specialists.

Across the period → Open-source agent frameworks narrow the capability gap significantly. Vendor lock-in resistance becomes the central enterprise procurement question rather than raw capability scores.

Key Takeaways

✅ Antigravity 2.0 is a platform shift, not a product upgrade — five surfaces, one shared harness, co-optimized with the model it runs on
✅ The mental model inversion is the real announcement — developers move from author to director, with specification quality and evaluation capability becoming primary skills
✅ Parallel agents change the economics of software production — the cost of producing complex artifacts drops significantly; the "not worth building" backlog gets smaller
✅ JSON hooks and project-level scoping are the underappreciated features — they're what make enterprise adoption credible
✅ The dual-wield workflow is Google's own recommendation — Antigravity 2.0 is designed to work alongside your existing IDE, with extensions for popular IDEs coming
⚠️ The biggest risk isn't hallucination — it's developer overconfidence in outputs they didn't produce and don't fully verify
⚠️ The /browser opt-in is a candid capability gap admission — watch for when this becomes autonomous; the capability jump will be significant
⚠️ Gemini CLI sunset is June 18, 2026 — if you're using it, this is urgent
🔍 The orchestration model generalizes well beyond code — legal, compliance, and knowledge work are the next proving grounds
🔍 No platform dominates all use cases — evaluate against your trust model, governance requirements, and ecosystem constraints

Conclusion

The demo everyone will share on social media is a Doom clone built on a fresh operating system for under a thousand dollars.

It is spectacular. It was designed to be spectacular.

But the lasting impact of Google I/O 2026 lies elsewhere.

Google is building a system where software development becomes an exercise in directing specialized intelligence toward meaningful outcomes — rather than manually producing every artifact yourself. The IDE metaphor, which has organized developer tooling for decades, is being deliberately replaced. In its place: a management surface for coordinated agents, designed from the ground up to extend beyond code into knowledge work broadly.

Whether that is liberating or unsettling probably depends on which skills you've built and how much you value the craft of writing code for its own sake.

But the economics are compelling, the infrastructure is shipping, and the direction is clear. The question for every engineering team, every technical leader, every solo builder working on a product today is not whether to engage with agentic development. It is how to build the evaluation capability, governance discipline, and architectural judgment that make agentic development produce outcomes you can actually trust.

The code has a new author.

Make sure you understand what it's writing.

What's your experience with agentic development workflows? I'm particularly interested in failure modes — the "under what conditions does this break?" stories are more useful to the community than the success cases. Share your perspective in the comments.

Tags: googleio ai programming productivity architecture

Environment variables vs connection references in Power Platform

SapotaCorp — Sun, 24 May 2026 06:06:24 +0000

Both environment variables and connection references exist for the same reason: a managed solution should import into Dev, Test, UAT and Prod without the developer editing anything between stages. They achieve that reason in different ways, and teams who conflate them end up with flows that either fail on import or run successfully against the wrong target system.

Here is the split we enforce, and the deployment-settings pattern that ties it together.

What each one is

Connection references are pointers to actual authenticated connections. A connection is the object that holds "here is my SharePoint authentication" or "here is my credential to Acme's REST API." A connection reference is a named slot that a flow uses instead of a direct connection.

When a managed solution imports into a new environment, connection references come in empty. They have to be bound to connections that exist in the target environment. First import pauses for the admin to create those connections; subsequent imports reuse them.

Environment variables are typed values - strings, numbers, JSON, booleans, secrets referenced from Azure Key Vault - that solution-aware code reads at runtime. A flow calls environmentVariables('acme_AcmeApiBaseUrl') and uses the returned value in an HTTP action.

The distinction: a connection reference represents who the flow connects as. An environment variable represents what the flow connects to.

The split we use

Connection reference for:

The SharePoint site the flow reads from
The SQL database the integration writes to
The custom connector to a client's billing system
Any authenticated service where the connector handles auth

Environment variable for:

API base URLs for custom REST endpoints hit via HTTP actions
Feature flags (acme_EnableCouponRedemption)
Tenant IDs, customer IDs, partition keys used in queries
Thresholds that differ per environment (rate limits, batch sizes)
Secret values from Key Vault via secret-type env variables

The smell test: does the flow authenticate with this thing? Connection reference. Is it a value the flow uses? Environment variable.

The deployment-settings.json pattern

When the pipeline imports a managed solution, the target environment needs values for every env variable and bindings for every connection reference. Both come from deployment-settings.json committed to the repo, one per target.

The pipeline step per target:

Secrets live in Key Vault, referenced by Key Vault URI from a secret-type env variable. Nothing sensitive lands in git.

Gotcha: env variable schema name typo

Definitions live inside the solution at Other/EnvironmentVariables.xml. The deployment-settings file references them by SchemaName. If the casing differs, you get either:

A hard fail at import with "environment variable not found," or
A silent success where the variable is unset and at runtime returns null

The second is the dangerous one. A flow that hits null for an API base URL will typically construct a malformed URL and fail at the HTTP call, with an error message that points at the HTTP action rather than the missing variable.

We now generate the deployment-settings skeleton from the solution XML instead of hand-writing it:

The team fills in the Values, never the SchemaNames. One class of typo gone.

Gotcha: connection reference not bound after first import

First import into a new environment leaves connection references empty. The solution import succeeds but the flows cannot run - they have no connection to authenticate through.

Two ways to handle this:

Interactive first import. An admin opens the solution post-import, binds each connection reference, turns flows on.
Pre-provisioned connections + deployment-settings. Admin creates the connections once, captures the connection IDs, puts them in deployment-settings/prod.json. The pipeline wires the references during the import.

Path 2 requires one-time manual work per connection per environment, then every future deploy is hands-off. Path 1 is fine for low-frequency deploys but burns human time on every release.

The handoff to client admins

When a client takes over admin of an environment we built, they get:

The deployment-settings file for their env, values they own left blank
A one-page runbook: what to check after a pipeline run (env variable values, connection reference bindings)
Their Key Vault URL if secret-type env variables are in use

The clearer the split is in our heads, the cleaner the handoff is for theirs.

Multi-BU D365 environment: single tenant, multiple LEs

SapotaCorp — Sun, 24 May 2026 06:06:03 +0000

Multinational corporations implementing D365 Finance & Operations across business units often underestimate how much the environment strategy decision will shape the next decade of their ERP life. Each business unit operating in a different industry brings its own processes, regulatory compliance, and data sensitivities. Picking the wrong structure at the start is expensive to reverse.

Three patterns surface in architecture workshops. Each has advocates; only one scales.

The two corner cases that fail

Single instance with one unified legal entity for all business units. Appealing for simplicity: one configuration, one security model, one master data set. Breaks immediately when BUs have different:

Fiscal calendars (calendar year vs fiscal year)
Chart of accounts detail (manufacturing vs services have fundamentally different GL structures)
Statutory reporting obligations (healthcare vs retail have distinct regulatory packages)
Intercompany boundaries (unified LE can't intercompany with itself)

The appeal wears off in the first cross-industry consolidation discussion.

Separate tenant per business unit. Isolates BUs completely. Produces predictable problems:

Cross-BU consolidated reporting becomes an Azure Synapse project
Every tenant has its own license, its own upgrade schedule, its own admin overhead
M&A that reorganizes BUs requires tenant migrations
Economies of scale in shared configuration disappear

Teams propose this pattern when they're nervous about sharing environments. Usually the fear is solvable with security boundaries inside a shared tenant.

Custom integration layer merging outputs from separate D365 environments. Builds a new system to fix a problem the platform already addresses. Permanent ongoing cost; introduces a new source of truth; slows every new BU onboarding.

The pattern that scales

Single tenant, multiple legal entities, with business unit isolation via organization hierarchies and security roles.

The architecture:

One D365 tenant hosting production + non-production environments
One legal entity per BU (or one per BU-and-country if BUs operate in multiple countries)
Country localization packages applied per LE as needed
Organization hierarchies - Corporate → BU → Operating Unit → Department - supporting both financial reporting cuts and security boundaries
Security roles scoped to BU via the organization hierarchy - a BU's users see only their BU's data despite sharing the tenant
Shared master data where BUs share vendors or customers, via global address book; BU-exclusive master data configured per-LE
Customizations in layered models - a Core model for shared logic, BU-specific models for industry variations, deployed together

The result: BUs operate with the independence they need, while corporate gets the consolidation, shared admin, and platform economics.

Organization hierarchy design

The hierarchy is how the tenant supports both financial and operational cuts:

Financial reporting hierarchy: LE ↔ BU ↔ Division ↔ Corporate. Rolls trial balances up for consolidation.
Operational hierarchy: LE ↔ BU ↔ Department ↔ Team. Drives security and workflow routing.
Legal hierarchy: LE ↔ Parent LE ↔ Ultimate parent. For statutory ownership disclosures.

Multiple hierarchies coexist. Each serves a specific purpose. Conflating them into one is a common design error.

Security model with BU isolation

Security inside a shared tenant keeps BU data separate via:

Legal entity scope on roles - a BU's accountants see only their LEs
XDS (Extensible Data Security) policies - row-level filtering beyond LE (e.g., department scope within an LE)
Organization hierarchy context in XDS - policies reference the user's BU via hierarchy
Centralized roles for corporate functions - corporate finance, corporate audit, IT admin roles span all LEs with approval

This is more work than "just use separate tenants" but gives the single-tenant economics without compromising data boundaries.

Customization layering per BU

F&O's extension model supports layered customizations. The pattern:

Foundation model - corporate-standard extensions that all BUs inherit (localization-specific tax extensions, centralized approval frameworks)
Industry models - shared extensions per industry for BUs in that vertical (manufacturing extensions, retail extensions)
BU-specific models - extensions unique to a single BU's needs

Each model version-controlled separately, deployed as a dependency chain. A BU's customization reaches them without polluting others.

ALM across BUs

With the multi-BU tenant, ALM has to support:

Shared build pipeline for foundation and industry models
Per-BU pipelines for BU-specific models
Environment strategy - dev per BU for BU-specific work, shared sandboxes for integration testing, shared UAT for coordinated testing, production shared by all BUs

The build coordination is the new complexity. Usually addressed by a center-of-excellence team that owns foundation + industry models and coordinates release trains with BU teams.

When separate tenants is right

There are rare cases where separate tenants genuinely fit:

Regulatory isolation required by law (certain defense or pharma scenarios)
Data residency conflicts that can't be resolved within one tenant's regional deployment
M&A scenarios where the acquired unit will eventually spin out
Extreme size difference where the BU's scale warrants its own admin team

Each of these is rare. The default for multi-BU multinationals is single tenant, multi-LE.

What ships with the pattern

A working multi-BU D365 tenant has:

Per-BU legal entities with appropriate localization
Organization hierarchies for financial and operational cuts
Security roles scoped to BU via hierarchy and XDS
Shared master data framework with BU-specific release patterns
Layered customization models (foundation, industry, BU)
CoE governance for shared configuration
ALM pipelines supporting the model layering

The pattern is boring because it's well-trodden. That's the point. Novel environment strategies are where multi-year regret accumulates.

AI API Integration Testing Checklist for Multi-Model Apps

Ye Allen — Sun, 24 May 2026 06:01:40 +0000

A single successful AI API request is not enough for production.

If your app uses GPT, Claude, Gemini, DeepSeek, Qwen, or other models through one OpenAI-compatible API gateway, I think the integration should be tested as a system: configuration, SDK compatibility, model names, JSON output, latency, retries, fallback, and Postman verification.

I published the full checklist here:

https://github.com/yeallen441-del/vectorengine-quickstart/blob/main/AI_API_TESTING_CHECKLIST.md

What I test before shipping

1. Base URL and API key

Most migration issues come from the wrong base URL, wrong API key, or unavailable model name. I test one small request with curl or Postman before touching production code.

2. SDK compatibility

For an OpenAI-compatible gateway, the goal is to keep the same OpenAI SDK request shape and only change the API key, base URL, and model name.

Example base URL:

https://www.vectronode.com/v1

3. Structured output

Many production workflows need valid JSON. I test whether the response parses, whether required fields exist, and how the app handles bad output.

4. Latency and fallback

A useful integration log should include model name, feature name, request duration, retry count, token usage, and error status.

These fields make it easier to decide when to use a premium model and when to route to a lower-cost fallback.

VectorNode AI is the OpenAI-compatible API gateway I am building around this workflow:

https://www.vectronode.com/

ORA-00203 오류 원인과 해결 방법 완벽 가이드

umzzil nng — Sun, 24 May 2026 06:01:10 +0000

ORA-00203: using the wrong control files 완벽 해결 가이드

ORA-00203란?

ORA-00203은 Oracle 데이터베이스가 시작(Startup) 과정에서 잘못된 컨트롤 파일(Control File)을 참조하려 할 때 발생하는 에러입니다. 컨트롤 파일은 데이터베이스의 물리적 구조(데이터 파일, 리두 로그 파일의 위치와 상태)를 기록하는 핵심 바이너리 파일로, Oracle 인스턴스가 마운트(MOUNT) 단계에서 이 파일을 읽지 못하거나 현재 인스턴스와 맞지 않는 파일을 읽으려 할 때 이 에러가 트리거됩니다. 주로 여러 Oracle 인스턴스가 공존하는 환경, 컨트롤 파일 복사 실수, 또는 RAC(Real Application Clusters) 환경에서 파라미터 파일(SPFILE/PFILE) 설정 오류로 인해 발생하며, 데이터베이스가 MOUNT 상태를 넘어서지 못하고 강제 종료되는 심각한 장애로 이어질 수 있습니다.

주요 발생 원인

1. SPFILE/PFILE의 CONTROL_FILES 파라미터 오설정

가장 빈번한 원인으로, CONTROL_FILES 파라미터에 지정된 경로가 실제 존재하는 컨트롤 파일의 경로와 불일치할 때 발생합니다. 특히 데이터베이스를 다른 서버로 이관(Migration)하거나 스토리지 경로가 변경된 이후에 SPFILE을 업데이트하지 않으면, 인스턴스는 이전 경로의 컨트롤 파일을 찾아 마운트를 시도하다 실패합니다. 또한 수동으로 PFILE을 편집하는 과정에서 오타나 경로 구분자 오류가 발생하는 경우도 매우 흔합니다.

2. 다중 인스턴스 환경에서 잘못된 컨트롤 파일 참조

하나의 서버에 여러 Oracle 인스턴스(SID)가 존재하는 환경에서, 특정 인스턴스의 파라미터 파일이 다른 인스턴스의 컨트롤 파일을 가리키는 경우에 발생합니다. 예를 들어 ORACLE_SID=PROD로 기동해야 할 인스턴스가 ORACLE_SID=TEST 환경의 컨트롤 파일을 참조하도록 설정되어 있다면, Oracle은 해당 컨트롤 파일이 현재 인스턴스와 맞지 않음을 감지하고 ORA-00203을 발생시킵니다. 이는 RAC 구성에서 노드별 파라미터 파일을 잘못 관리했을 때도 동일하게 발생합니다.

3. 컨트롤 파일 손상 또는 불완전한 복사

컨트롤 파일이 OS 레벨에서 손상(Corrupt)되었거나, 데이터베이스가 열려 있는 상태에서 OS 명령(cp, copy)으로 복사된 불완전한 파일을 참조할 때 발생합니다. Oracle 컨트롤 파일은 데이터베이스 운영 중에도 지속적으로 갱신되는 파일이므로, 활성화된 상태에서 OS 레벨 복사를 수행하면 내부 일관성이 깨진 파일이 생성됩니다. 이런 파일을 이후 복구 시나리오에서 사용하게 되면 반드시 ORA-00203과 함께 추가적인 에러가 연쇄적으로 발생합니다.

해결 방법

원인 1 해결: CONTROL_FILES 파라미터 수정

먼저 현재 인스턴스가 어떤 컨트롤 파일을 참조하려 하는지 확인합니다.

-- NOMOUNT 상태에서 파라미터 확인
STARTUP NOMOUNT;

-- 현재 파라미터 파일에 설정된 CONTROL_FILES 확인
SHOW PARAMETER control_files;

-- 또는 V$PARAMETER 뷰를 통해 확인
SELECT name, value
FROM   v$parameter
WHERE  name = 'control_files';

OS 레벨에서 실제 컨트롤 파일이 어디에 존재하는지 확인한 후, SPFILE을 수정합니다.

-- SPFILE의 CONTROL_FILES 파라미터 수정 (NOMOUNT 상태에서 가능)
ALTER SYSTEM SET control_files =
    '/u01/app/oracle/oradata/PROD/control01.ctl',
    '/u01/app/oracle/oradata/PROD/control02.ctl',
    '/u01/app/oracle/fast_recovery_area/PROD/control03.ctl'
SCOPE = SPFILE;

-- 변경 후 데이터베이스 재시작
SHUTDOWN IMMEDIATE;
STARTUP;

PFILE을 사용하는 경우, 직접 파일을 편집합니다.

-- 현재 SPFILE로부터 PFILE 생성 (수동 편집용)
CREATE PFILE = '/tmp/init_PROD_backup.ora' FROM SPFILE;

# /tmp/init_PROD_backup.ora 파일 내 아래 항목을 실제 경로로 수정
*.control_files='/u01/app/oracle/oradata/PROD/control01.ctl',
                '/u01/app/oracle/oradata/PROD/control02.ctl'

-- 수정된 PFILE로 기동
STARTUP PFILE='/tmp/init_PROD_backup.ora';

-- 정상 기동 확인 후 SPFILE 재생성
CREATE SPFILE FROM PFILE='/tmp/init_PROD_backup.ora';

원인 2 해결: 올바른 인스턴스 환경 변수 설정 및 파라미터 검증

다중 인스턴스 환경에서는 반드시 환경 변수를 먼저 확인합니다.

# OS 레벨에서 현재 ORACLE_SID 확인
echo $ORACLE_SID
echo $ORACLE_HOME

# 올바른 SID로 환경 변수 재설정 (bash 기준)
export ORACLE_SID=PROD
export ORACLE_HOME=/u01/app/oracle/product/19.3.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

-- 각 인스턴스별 SPFILE 경로 확인
-- PROD 인스턴스의 SPFILE은 반드시 PROD 전용 컨트롤 파일을 참조해야 함
STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initPROD.ora';

-- 컨트롤 파일의 DB_NAME과 현재 인스턴스 일치 여부 확인
-- (MOUNT 성공 후 가능)
SELECT name, db_unique_name, created
FROM   v$database;

-- 컨트롤 파일 상태 전체 조회
SELECT name, status, is_recovery_dest_file
FROM   v$controlfile;

RAC 환경에서는 각 노드별 파라미터 파일 분리 여부를 점검합니다.

-- RAC 환경: 인스턴스별 파라미터 확인
SELECT inst_id, name, value
FROM   gv$parameter
WHERE  name = 'control_files'
ORDER BY inst_id;

원인 3 해결: 컨트롤 파일 복구

컨트롤 파일이 손상된 경우, RMAN을 통한 복구가 가장 안전합니다.

-- RMAN으로 컨트롤 파일 복구
-- 먼저 NOMOUNT 상태로 기동
STARTUP NOMOUNT;

# RMAN 접속 후 복구 수행
rman target /

-- RMAN: 자동 백업으로부터 컨트롤 파일 복구
RESTORE CONTROLFILE FROM AUTOBACKUP;

-- 또는 특정 백업 세트로부터 복구
RESTORE CONTROLFILE FROM '/backup/PROD/ctrl_backup_20240115.bkp';

-- 복구 완료 후 마운트
ALTER DATABASE MOUNT;

-- 데이터베이스 복구 및 오픈
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

컨트롤 파일 백업본이 전혀 없는 최악의 경우, 트레이스 파일로부터 재생성을 시도합니다.

-- 정상 DB에서 미리 컨트롤 파일 재생성 스크립트 추출 (예방 목적)
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
AS '/backup/controlfile_recreate.sql' REUSE RESETLOGS;

-- 추출된 스크립트 예시 (손상 시 NOMOUNT 상태에서 실행)
CREATE CONTROLFILE REUSE DATABASE "PROD" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/app/oracle/oradata/PROD/redo01.log'  SIZE 200M BLOCKSIZE 512,
  GROUP 2 '/u01/app/oracle/oradata/PROD/redo02.log'  SIZE 200M BLOCKSIZE 512,
  GROUP 3 '/u01/app/oracle/oradata/PROD/redo03.log'  SIZE 200M BLOCKSIZE 512
DATAFILE
  '/u01/app/oracle/oradata/PROD/system01.dbf',
  '/u01/app/oracle/oradata/PROD/sysaux01.dbf',
  '/u01/app/oracle/oradata/PROD/undotbs01.dbf',
  '/u01/app/oracle/oradata/PROD/users01.dbf'
CHARACTER SET AL32UTF8;

예방 방법

1. 컨트롤 파일 다중화 및 정기적인 RMAN 자동 백업 설정

컨트롤 파일은 반드시 서로 다른 디스크(또는 ASM 디스크 그룹)에 최소 3개 이상 다중화하여 단일 장애점(SPOF)을 제거해야 합니다. 또한 RMAN의 CONFIGURE CONTROLFILE AUTOBACKUP ON 설정을 활성화하면 백업 및 구조 변경 시마다 컨트롤 파일이 자동으로 백업되어, 손상 발생 시 신속한 복구가 가능합니다.

-- 컨트롤 파일 자동 백업 활성화 (RMAN)
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
    FOR DEVICE TYPE DISK TO '/backup/%F';

-- 현재 다중화 설정 확인
SELECT name FROM v$controlfile;

-- 컨트롤 파일 재생성 스크립트를 주기적으로 백업 (크론잡 등록 권장)
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
AS '/backup/scripts/controlfile_ddl_$(date +%Y%m%d).sql';

2. 변경 관리 절차(Change Management) 준수 및 파라미터 파일 형상 관리

운영 환경에서 스토리지 경로 변경, 인스턴스 추가, 서버 이관 등의 작업 시에는 반드시 CONTROL_FILES 파라미터를 포함한 SPFILE 전체를 변경 전후로 백업하고, 변경 이력을 문서화해야 합니다. Git 등의 형상 관리 도구를 활용하여 PFILE/SPFILE 내용을 버전 관리하면, 잘못된 변경 발생 시 즉시 이전 상태로 롤백할 수 있습니다.

-- 작업 전 현재 SPFILE을 PFILE로 백업 (날짜 포함)
CREATE PFILE='/backup/config/initPROD_before_20240115.ora' FROM SPFILE;

-- 변경 후 검증
SHOW PARAMETER control_files;

-- 정기적인 파라미터 스냅샷 저장 (모니터링 테이블 활용)
CREATE TABLE dba_param_snapshot AS
SELECT SYSDATE snap_time, name, value
FROM   v$parameter
WHERE  name IN ('control_files', 'db_name', 'db_unique_name');

에러 코드	설명
ORA-00200	`control file could not be created` — 컨트롤 파일 생성 자체가 실패한 경우
ORA-00201	`control file version X incompatible with ORACLE version Y` — 컨트롤

Designing a Data Extension in SFMC: The Four Decisions First

SapotaCorp — Sun, 24 May 2026 06:00:37 +0000

Almost every new SFMC engagement starts the same way. The client sends a 40-column Excel file of customer data and says "import this into SFMC." The team creates a Data Extension that mirrors the Excel columns. Two weeks later the DE can't send email, can't relate to other DEs, and one field won't import because the data type is wrong.

The fix is four decisions made before the DE is created, not after.

Decision 1: What is this DE for?

Sendable DE: will be used to send email. Tick "Is Sendable" in Properties. Must have a field of type EmailAddress and a Subscriber Key relationship.
Lookup DE: stores reference data that AMPscript looks up at send time (sales rep list, product catalog, store locations). Not sendable, no EmailAddress required.

Pick before creating. Adding Is Sendable after the fact is possible but annoying; getting the Subscriber Key relationship right on an existing DE with data is error-prone.

Decision 2: What's the Primary Key?

Primary Key is the column that uniquely identifies each record. Rules:

Must be unique across all records in the DE.
For sendable DEs, use a system ID like CustomerID or MemberID. Don't use EmailAddress - one person can have multiple email addresses, and some people change addresses.
For lookup DEs, use the natural ID of the entity (SalesRepID, ProductID).

Decision 3: Which fields are nullable?

Non-nullable means the field is required. If an imported row is missing it, the row is rejected.
EmailAddress and Primary Key should almost always be non-nullable.
Demographic fields (address, phone, birthday) are often nullable because source data isn't always complete.

Importing a file full of rows with missing non-nullable fields and wondering why half the rows vanished is a standard first-week mistake.

Decision 4: Are the data types right?

Data typeUse forTextNames, mixed alphanumeric IDs, addressesNumberInteger IDs, point balancesEmailAddressMust be used for the email column - SFMC validates formatDateBirthdays, expiry dates (format must match on import)BooleanFlags like IsVIP, HasPurchasedDecimalMonetary amounts, anything with a fractional component

Classic import failure: OrderNumber values like ORD-00123 imported into a Number field. The letters break it. Use Text.

Four mistakes we still see on audits

Forgot to set Is Sendable

DE doesn't appear in the audience picker when you go to send. Edit Properties, tick Is Sendable, configure the Send Relationship. Avoidable if you decide at creation time.

Using EmailAddress as Primary Key

Customer updates their email. Import runs. The old row with the old email still exists. New row with the new email is added. One person is now two records. Audience counts lie.

Use a stable system ID. Email is an attribute, not an identity.

Two EmailAddress-type fields in one DE

SFMC does not allow two fields with data type EmailAddress in the same DE. If you have both EmailAddress and SecondaryEmail typed as EmailAddress, sends from this DE fail completely - no one gets the email.

One of the two must be typed as plain Text.

Field length too short

Setting FullName length to 50 characters seems reasonable until a customer with a longer name gets truncated or rejected. Two consequences:

Data integrity: you silently lose data.
Import speed: SFMC can process imports faster when field lengths are accurately sized.

Size fields to the longest realistic value, not the median.

The Create-from-Existing shortcut

When you need a new DE with a structure similar to an existing one (e.g. Customer_Segment_VIP with most fields from Customer_Master), use Create from Existing in Content Builder > Data Extensions. It copies the full schema: field names, types, lengths, nullable flags. You only add or remove the fields that need to differ.

Create from Template is for SFMC's preset schemas (Triggered Send DE, Tracking DEs, etc.), not your own DEs. Different tool.

Takeaway

Four decisions before you click Create: purpose (sendable/lookup), Primary Key, nullable fields, data types. Thirty seconds of thinking saves rebuild work later. When you inherit a project with half-broken DEs, the common root cause is always one of these four being wrong.

Starting an SFMC project with messy source data? Our Salesforce team designs Data Extensions and data models on production engagements. Get in touch ->

See our full platform services for the stack we cover.

I Got Tired of Heavy Design Tools😩… So I Built My Own

Mohamed Ibrahim — Sun, 24 May 2026 06:00:00 +0000

Like the title says, I got tired of heavy design tools… so I built my own.

I wanted something simple, fast, and focused — no complicated setup, no unnecessary features, and absolutely NO TIME WASTED.

Every time I wanted to create a quick transparent PNG, logo mockup, or simple social media graphic, I ended up wasting time.

Open a design tool.
Create an account.
Verify email.
Wait for assets to load.
Deal with unnecessary features.
Get annoying emails every week trying to sell you premium features.

UGHHHH 😩😩😩

Sometimes I just wanted to open a website and start designing instantly.

So I built something for myself.

And that project became Editsify.

What is Editsify?

Editsify is a lightweight browser-based design tool focused on simplicity and speed.

The goal was simple:

Open the website
Start designing immediately
Export transparent PNG images easily
No sign-up
No complicated dashboard
No unnecessary features

Everything runs directly in your browser.

Why I Built It

Most design tools today are powerful — but sometimes too powerful.

If you're trying to quickly:

Create a transparent PNG
Make a simple thumbnail element
Design a logo concept
Create social media assets
Share a quick design with someone

...you probably don't need a massive editor with hundreds of menus.

I wanted something minimal, fast, and distraction-free.

The Feature I Personally Love Most

One thing I really wanted was easy design sharing.

With Editsify, you can share your design with another person instantly so they can preview it or continue working on it.

And the interesting part?

You still don't need an account.

No login system.

No forced registration.

No complicated setup.

Just create and share.

Everything is Stored Locally

Another thing I care about a lot is privacy and speed.

Your design data is stored directly inside your browser instead of being uploaded somewhere automatically.

That means:

Faster experience
Less waiting
More privacy
Simpler workflow

Who is This Tool For?

I think Editsify is useful for:

Content creators
YouTubers
Designers who need quick assets
Developers making UI elements
People who just want transparent PNG images fast

Especially if you hate wasting time before starting actual work.

Still Improving It

The project is still growing, and I’m continuously improving the editor and adding new features.

I mainly built it because I personally needed something simpler than traditional design tools.

But now other people are starting to use it too, which is honestly exciting to see.

I’ve also been thinking about making parts of Editsify open source in the future so developers can contribute and build cool things around it.

If the project gets enough support and community interest, I’d genuinely love to make that happen.

Try It

If you want to test it yourself:

Editsify

I’d genuinely love to hear feedback, ideas, or feature suggestions.

Kayrol — Day 0: Building AI highlight reels for athletes (in public)

juan barrera — Sun, 24 May 2026 05:59:28 +0000

I started building Kayrol this weekend. Here's what Day 0 looks like:
the problem, the stack, and the plan for the next 4 weeks.

I'm Juan, a CS student + mid-level dev who is currently an student-athlete. Last year I was exactly where my target customers
are: grinding scholarships, building a portfolio, hoping someone
would notice me.

The Problem

Athletes have HOURS of game footage. Scouts watch 30 seconds. We're
losing talent to bad marketing of ourselves.

That's the gap I'm filling.

What I'm Building

Kayrol — a SaaS that auto-generates highlight reels from raw game
footage using AI + gives coaches/scouts performance analytics per match.
Bilingual ES/EN from day one.

Why it matters:

Scholarship recruiting agencies in LATAM handle 50-60 athletes/year, charge $1,500-3,000 per athlete
They manually edit highlights → I automate it
Athletes pay $25/game or $59/month (vs $400+ Hudl/Veo)

The competition:

Athlete AI (USA, multi-sport mediocre, English-only, $5-20/month)
Trace ($180-300/year + mandatory hardware)
Veo Camera ($2,000+ hardware)
Hudl (expensive, built for teams not individuals)
Traditional agencies (NCSA, IFX, New Vision: $1,000-3,000 per athlete)

My unfair advantage:

Software-only, no hardware required
Bilingual from day one
Built for soccer specifically
I am the customer (Student athlete)
80% cheaper than incumbents

What I Built (Day 0)

Saturday, May 23, 2026 — project started:

Next.js 16 + TypeScript (full i18n setup for ES/EN)
Supabase for auth + database
Cloudflare R2 for video storage
Dev environment ready, repo structured for scale

Tech decisions made me ask: Does this stack actually make sense for
video processing at scale? (Feedback welcome on this)

Validation So Far

15 athletes interviewed — pain point confirmed
1 recruiting agency (close friend, 50-60 athletes/year) committed to paying $199 USD for a 30-day pilot with 10 athletes
Same agency said they'd pay $500-1,000+/month for full version

The 4-Week Plan

Week 1-2: Auth flow + video upload infrastructure

Week 3: Video processing + basic analytics

Week 4: Landing page + pilot launch with first agency

I'm dedicating 30-40h/week to this. Solo build, no co-founder yet.

What I'm Looking For

Tech feedback: Does Next.js + Supabase + R2 make sense for
video-heavy SaaS at scale? Better alternatives?
Recruiting agencies interested: 30-day pilot, 10 athletes, $199.
(Already have 1 committed, looking for 2-3 more)
Athletes/coaches: What would actually make you use something
like this? What's missing?

The Journey

I'm building this in public. Not because it's trendy, but because:

I need accountability
Feedback loops matter
Founders building something similar can learn from my mistakes

Next post: Auth flow + first video ingest working.

Repo: github.com/jdexbarr/Kayrol (will make public after MVP)

Website: kayrol.com (landing page coming soon)

Let's go 🚀

The Agony of Over-Engineered Operators: Why Simplicity Saved Our Treasure Hunt Engine

pretty ncube — Sun, 24 May 2026 05:56:05 +0000

The Problem We Were Actually Solving

As a systems engineer, I've had my fair share of battles with the age-old problem of over-engineering. Recently, I encountered it in the form of our company's treasure hunt engine, a large-scale event scheduling system that needed to handle thousands of concurrent requests with minimal latency. We were tasked with optimizing the engine to ensure it could scale to meet the growing demand. To my surprise, the root of the problem lay not in the database, nor in the caching layer, but in the operators used to build the system.

What We Tried First (And Why It Failed)

Our initial attempt at optimizing the engine involved using a complex state machine-based operator to manage the events and their associated metadata. This operator allowed us to achieve high-level abstractions and make decisions based on a wide range of factors, including event priority, user permissions, and system load. Sounds great, right? Unfortunately, this approach had a few unintended consequences. Firstly, it introduced a significant amount of complexity, making it increasingly difficult to understand and maintain the codebase. Secondly, the overhead of the state machine led to increased latency and resource utilization, which in turn caused the system to become a bottleneck.

The Architecture Decision

After weeks of debugging and profiling, it became clear that we needed to simplify our operator implementation. We ditched the state machine and switched to a more straightforward, rule-based approach. This decision not only reduced the code's footprint but also improved the overall performance by eliminating the need for recursive state transitions. We replaced the complex operator with a simple, linear sequence of conditional checks and actions. This change allowed us to not only reduce the latency but also make the code more predictable and easier to debug.

What The Numbers Said After

Here are some key metrics that illustrate the impact of our change:

Allocation Count: Using the old state machine-based operator, we were allocating an average of 1,500 objects per second. After switching to the new approach, this number dropped to 200 objects per second.
Latency: Prior to the change, our average response time was around 500ms. With the new operator, we saw an average response time of 150ms.
Memory Utilization: Our memory usage decreased by 30% due to the reduced allocation count and lower state machine overhead.

What I Would Do Differently

In retrospect, I would have caught the complexity issue much earlier by focusing more on the system's overall dependencies and bottlenecks. While it's easy to get caught up in the excitement of implementing new features and abstractions, the reality is that simple, straightforward solutions often work best in the long run. By being more mindful of the architecture's implications and trade-offs, I believe we could have avoided the complexity spiral and arrived at the simple solution more quickly.

Business Rules vs Power Automate vs Plugin: pick one

SapotaCorp — Sun, 24 May 2026 05:54:49 +0000

A new requirement lands: "When an opportunity's amount exceeds 50,000, flag it for legal review and notify the deal desk." Every developer who has worked in Dataverse for more than six months has four places they could put this logic. Half the arguments on a mature team are about which place is the right one.

Here is the decision tree we run, with the cost, latency and maintainability trade-offs that actually play out in production.

The four options

Business Rule. Declarative, runs client-side in model-driven forms. Can set field values, show/hide fields, set requirement levels. Cannot call other services.

Power Automate cloud flow. Asynchronous, server-side. Triggered by Dataverse table events (create, update, delete). Can call any connector - Dataverse itself, SharePoint, HTTP endpoints, anything. Visual designer.

Classic workflow. Legacy equivalent of Power Automate, lives inside Dataverse. Still supported for some patterns (synchronous custom actions, rollup field recalculation) but Microsoft's direction is Power Automate.

Plugin (custom code). C# class that registers against the Dataverse execution pipeline. Runs server-side, can be synchronous (inside the original database transaction) or asynchronous. Full .NET, full Dataverse SDK.

The decision tree

Where each one breaks

Business Rules break when:

You need to run on API writes (they only fire in model-driven forms)
You need conditional logic beyond AND/OR on field values
You need to call external services

In practice, Business Rules are useful for exactly one pattern: "when field A has value X, show/require field B." Anything more complex becomes unreadable fast.

Power Automate breaks when:

You need to block a save on validation failure (Power Automate is always async from a Dataverse write's perspective)
You need sub-second latency (typical cold-start latency is 3-10 seconds for a new flow run)
You are in a high-volume scenario - flow runs cost against your per-seat or per-flow licensing

The licensing trap is real. A plugin on a write trigger fires for free. A Power Automate flow on the same trigger consumes one run per event. A Dataverse table that sees 500,000 writes per day under a per-flow-plan license ($100/month for 3 flows) is fine; under per-user-plan licensing, the math needs checking.

Plugins break when:

You need visual configurability for non-developers to maintain
You call external HTTP endpoints from sync code (2-minute plugin timeout + slow HTTP = failures)
You want a non-developer to understand what it does by reading it

Plugins are the right hammer for high-volume, low-latency, Dataverse-internal logic. They are the wrong hammer when the "requirements" column in the ticket is a paragraph a business analyst will revise weekly.

Classic workflows we avoid for new work. Microsoft's documentation repeatedly nudges toward Power Automate, and we take the hint.

Case: the opportunity-flagging requirement

Back to "When an opportunity's amount exceeds 50,000, flag for legal review and notify deal desk."

Decompose into two actions:

Flag for legal review - a boolean field acme_requires_legal_review set to true. This is a row modification, needs to run on every save (UI or API), should block the save from proceeding if other logic depends on the flag.Plugin, synchronous, pre-operation. Ten lines of C# in a well-named step.
Notify deal desk - send an email or Teams message. Not time-sensitive (hours of latency fine), needs to integrate with Outlook or Teams connectors.Power Automate cloud flow, triggered on update of acme_requires_legal_review = true.

Two tools, one requirement. The split falls out of the "does it modify the row" and "does it integrate with non-Dataverse" questions.

Teams who pick one tool for everything end up with either:

A 40-step Power Automate flow that does both, times out occasionally, and breaks silently when the notification connector has a bad day
A plugin that sends emails via System.Net.Mail, fails auth against Exchange Online, and exposes SMTP credentials in code

Two targeted tools working together beats one tool stretched past its good use.

The review we run before merging

On every pull request that adds logic, the reviewer asks four questions:

Is this the right tool? (Walk through the decision tree above.)
If it is a plugin, is it in the right pipeline stage? (Pre-validation vs pre-operation vs post-operation - each has different semantics.)
If it is a flow, is it idempotent? (Retries happen; a flow that double-charges a customer on retry is a problem.)
Is the logic named and documented so a new team member can find it?

Question 4 is the one teams skip most. Dataverse gives you four places to put logic; unless a newcomer can find which one you chose, they will add their own in a fifth place.

Dataverse virtual tables on SQL: three latency patterns

SapotaCorp — Sun, 24 May 2026 05:54:29 +0000

Virtual tables let Dataverse surface data that lives in another system - SQL Server, Cosmos DB, a REST API - without copying it into Dataverse. The user-facing experience is the same as any table: views, forms, lookups, relationships. The underlying retrieval goes out over the wire to the external source on every read.

On paper, the appeal is obvious: no sync, no duplication, always current. In practice, the latency characteristics are what decide whether virtual tables fit the use case. Here are the three patterns we benchmark on every project that proposes virtual tables, and the rules we apply.

What virtual tables are (and are not)

A virtual table in Dataverse is defined by:

A virtual entity (the table schema)
A virtual entity provider (the bridge between Dataverse and the external source)
Metadata mapping (column names and types from the external source to the Dataverse view)

When a user opens a view of the virtual table, Dataverse calls the provider. The provider queries the external source. Results come back and are rendered.

Crucially:

No data is persisted in Dataverse. The virtual table has zero rows stored.
Relationships to native tables are limited. You can have a lookup from a native table to a virtual table; you cannot have rollups or complex cross-table queries involving virtual tables.
No audit, no field-level security, no duplicate detection. Features that rely on storing data in Dataverse do not apply.

The benchmark we run

Before committing to a virtual table, we run a three-scenario benchmark:

Single-row lookup: fetch one row by primary key. "Open the detail form."
List view: fetch 50 rows with a filter. "Load the default view of active orders."
Integration write + read-back: a native-table row gets created with a lookup to the virtual table; the form immediately displays joined data.

We measure end-to-end latency from the Power Platform host making the call to the response being renderable. Targets:

Single-row lookup: under 500ms
List view: under 1200ms
Write + read-back: under 2 seconds

Pattern 1: SQL Server behind the virtual table, local-region

Benchmark typical for a SQL Server database hosted in the same Azure region as the Dataverse environment, under normal load:

Single-row lookup: 150-300ms (good)
List view: 400-900ms (good)
Write + read-back: 800-1500ms (marginal but workable)

The dominant cost is the network round trip plus the SQL query plan. Co-located SQL performs acceptably for most scenarios.

When this pattern works: order history lookups, reference data where the source of truth is a warehouse database, reporting-like views where the data is massive and duplicating it is impractical.

Pattern 2: REST API behind the virtual table, internet-routed

API hosted on the client's infrastructure or a third-party service, not co-located:

Single-row lookup: 800-1500ms (marginal)
List view: 2000-5000ms (poor)
Write + read-back: 3000-6000ms (fails the 2-second budget)

The API call adds 300-800ms baseline latency per call. Lists of 50 rows that require multiple backend queries compound quickly.

When this pattern fails: anything user-facing that sees more than 50 rows at a time. Form-by-form lookup works; view loading does not.

When this pattern can work: low-volume scenarios where users tolerate loading spinners, reference data that changes rarely and can be cached aggressively.

Pattern 3: virtual table with provider-side caching

The clever play: between Dataverse and the external source, insert a cache (Redis, Cosmos DB with TTL, or SQL Server acting as a cache table). The virtual entity provider reads from the cache; a separate process keeps the cache fresh from the real source.

Single-row lookup: 80-150ms (excellent)
List view: 200-500ms (excellent)
Write + read-back: 400-800ms (good)

Trade-off: the cache introduces staleness. A row changed in the backing source may not appear in Dataverse for seconds-to-minutes, depending on the cache refresh strategy.

When this pattern works: high-volume read, low-volume write, users tolerate brief staleness. Most reporting and reference data scenarios.

When this pattern complicates: the cache is now a separate system to monitor, invalidate, and age. Added operational surface.

The three questions before choosing virtual tables

How much data is there?

Under 100,000 rows and growing slowly: just copy it into a native Dataverse table via a dataflow. You get all the platform features and no performance concerns.

Over 10 million rows, or rapidly growing: virtual table starts to look attractive. Storing 10M rows in Dataverse costs capacity and money.

Between those: judgment call based on the other two questions.

How often does the data change?

Changes rarely (reference data, historical records): a native table with periodic sync via dataflow is fine. Virtual table gives you no advantage.

Changes frequently (live operational data, real-time trading, IoT telemetry): virtual table can be appropriate if the source supports it; otherwise, a sync + cache pattern is needed.

How do users interact with it?

Browse and drill-down (list views, detail forms): virtual table works if latency is acceptable per Pattern 1 or 3.

Bulk operations (mass edits, imports, reporting queries across millions of rows): virtual table is not suitable. The external source would be hammered; Dataverse would time out.

Lookup field targets (native tables referencing the virtual table's rows): works, but any navigation breaks rollups and calculated columns.

The bake-off we did last year

A client wanted their 15-million-row order history from SQL Server accessible in the Dynamics Sales UI. Three options evaluated:

Copy all 15M rows into Dataverse: $$$ on Dataverse capacity, monthly sync refreshes, stale data for up to 24 hours.
Virtual table, direct to SQL: real-time data, no storage cost, per-request latency of 400-900ms per view.
Virtual table with Cosmos DB cache: near-real-time data (30-second cache TTL), fast reads (150-300ms), added operational complexity.

We benchmarked all three in a UAT environment clone. Option 1's cost was $12,000/year in Dataverse storage alone. Option 2's view load time was borderline at peak hours (SQL contention). Option 3 won on price and performance.

The one caveat: option 3 requires operational investment to keep the cache healthy. We built a monitoring dashboard and a cache-warm routine on top of it. The client's internal team took this on after handoff; it has been stable for nine months.

When we don't recommend virtual tables

Three scenarios where we steer the client away from virtual tables entirely:

Heavy write scenarios. Virtual table providers have to implement Create/Update/Delete, and debugging provider-side transaction semantics is an order of magnitude harder than debugging normal CRUD.
Feature requirements that need Dataverse native behavior. Field-level security, audit, alerts, duplicate detection, business process flows - none of these apply to virtual tables.
Low-volume reference data. Under 5000 rows, just copy it. The engineering time saved is worth the capacity cost.

Virtual tables are a powerful tool for specific scale and data-freshness requirements. They are the wrong first answer for most "we have existing data in another system" cases. Copy the data unless there is a specific reason not to.