Mert

Most engineering organisations do not fail because their developers are untalented.

They fail because their communication structures, ownership boundaries, and operational dependencies create friction that compounds over time.

A deployment takes three weeks because four teams must approve it. A platform team becomes a ticket queue instead of a product team. Stream-aligned teams spend more time negotiating dependencies than shipping software. Cognitive overload silently accumulates until incident frequency rises and delivery velocity collapses.

These are not tooling problems.

They are topology problems.

The framework introduced in the book Team Topologies by Matthew Skelton and Manuel Pais provides one of the clearest operational models for designing engineering organisations around flow rather than hierarchy.

The core idea is deceptively simple

Optimise team structures for fast, sustainable software delivery.

This article explains how to apply Team Topologies in practice, identify the organisational anti-patterns slowing your DevOps initiatives, and implement structural changes that improve delivery speed without creating organisational chaos.

Why Team Structure Matters in DevOps

DevOps is often described as a tooling movement.

It is not.

It is fundamentally a sociotechnical systems discipline.

Tooling matters. Automation matters. CI/CD matters.

But organisational communication paths ultimately determine delivery speed.

Conway’s Law famously states:

Organisations design systems that mirror their communication structures.

Meaning:

• Fragmented teams create fragmented systems
• Bottlenecked organisations create bottlenecked architectures
• High-friction communication creates high-friction delivery

Team Topologies provides a practical framework for reducing those organisational bottlenecks systematically.

The 4 Team Types

The Team Topologies model defines four fundamental team types.

Each exists to solve a distinct operational problem.

1. Stream-Aligned Teams

These are the primary delivery teams.

A stream-aligned team owns a flow of business value end-to-end.

Examples:

• Payments platform
• Customer onboarding
• Mobile checkout
• Recommendation engine

The key principle:

Single team → owns service lifecycle completely

Including:

• Development
• Deployment
• Operations
• Monitoring
• Incident response

Characteristics of Strong Stream-Aligned Teams

Healthy stream-aligned teams typically:

• Deploy independently
• Own production support
• Minimise external dependencies
• Have clear business alignment
• Operate autonomously

Example structure

Team: Payments
Ownership:
- Payment API
- Fraud checks
- Transaction database
- Deployment pipelines
- Monitoring dashboards

This dramatically reduces coordination overhead.

Warning Signs

Stream-aligned teams fail when:

• Too many systems are owned
• Multiple domains are mixed together
• External dependencies dominate delivery
• Teams lack operational authority

The result is cognitive overload.

2. Enabling Teams

Enabling teams exist to help other teams improve capabilities.

Not to permanently do the work for them.

Examples:

• Kubernetes adoption team
• SRE coaching team
• Security enablement team
• Observability specialists

Their role is temporary acceleration.

Not long-term ownership.

Healthy Enabling Team Behaviour

Good enabling teams:

• Teach
• Coach
• Pair
• Document
• Reduce friction
• Transfer knowledge

Bad enabling teams become outsourced implementation departments.

That destroys scalability.

Example: Kubernetes Enablement

Good pattern:

Enabling Team:
- Creates templates
- Runs workshops
- Helps first deployments
- Coaches incident response

Bad pattern

Every Kubernetes deployment requires enabling team intervention forever

That becomes another bottleneck.

3. Complicated Subsystem Teams

Some domains require deep specialist expertise.

Examples:

• ML inference systems
• Real-time video encoding
• Cryptography engines
• High-frequency trading systems

These are cognitively dense domains unsuitable for broad ownership.

Dedicated specialist teams reduce complexity exposure for the rest of the organisation.

Why This Team Type Exists

Without complicated subsystem teams

Every stream-aligned team
↓
Must understand advanced specialist systems

This overwhelms cognitive capacity rapidly.

Example

A recommendation-engine ML platform might require:

• Tensor optimisation
• GPU scheduling
• Feature stores
• Embedding pipelines

That expertise does not belong inside every product team.

4. Platform Teams

Platform teams build internal developer platforms.

Their mission

Reduce cognitive load for stream-aligned teams.

Platform teams should operate like product teams.

Not internal ticket queues.

Platform Team Responsibilities

Typical responsibilities:

• CI/CD systems
• Kubernetes platforms
• Observability tooling
• Secrets management
• Golden deployment paths
• Infrastructure templates

Platform-as-a-Product

This concept is critical.

A healthy platform team provides

Self-service capabilities

Not manual intervention.

Good platform

Developer clicks button → environment created

Bad platform

Developer opens Jira ticket → waits 2 weeks

The 3 Interaction Modes

The framework also defines three interaction patterns between teams.

These interaction modes are enormously important operationally.

1. Collaboration Mode

Temporary close cooperation between teams.

Used for:

New capability adoption
Complex integrations
Discovery work

Example

Payments Team ↔ Platform Team

Working together to implement service mesh adoption.

The Key Word: Temporary

Permanent collaboration indicates unclear boundaries.

Collaboration mode should end eventually.

Otherwise dependency chains become permanent.

2. X-as-a-Service Mode

One team provides services consumed independently by others.

This is the desired long-term state for platform teams.

Example

Platform Team → Kubernetes Platform

Consumed self-service by product teams.

Minimal synchronous interaction required.

Signs Your Platform Interface Is Healthy

Healthy X-as-a-Service characteristics:

• Well documented
• Self-service
• Stable APIs
• Clear support boundaries
• Minimal tickets required

3. Facilitating Mode

Used by enabling teams.

Purpose

Teach capability
Not own capability

Examples:

• Security workshops
• Incident response coaching
• Terraform migration guidance

Facilitating mode transfers knowledge intentionally.

Assessing Your Current Topology: The 6 Key Questions

Most organisations already feel their topology pain intuitively.

This framework helps diagnose it systematically.

Question 1: How Many Teams Are Required for a Deployment?

If the answer exceeds three consistently

Flow efficiency is already degraded.

Question 2: Are Platform Teams Productive or Ticket-Driven?

Platform teams buried in support queues are usually under-designed.

Question 3: Is Production Ownership Clear?

During incidents

Who owns this?

Should never require debate.

Question 4: How Much Cognitive Load Exists Per Team?

Too many technologies, domains, or dependencies create delivery paralysis.

Question 5: How Often Are Teams Waiting on Other Teams?

Dependency-heavy organisations slow exponentially as headcount grows.

Question 6: Are Teams Optimised Around Technology or Business Flow?

Technology-aligned teams often create excessive handoffs.

Business-stream alignment improves delivery velocity dramatically.

Cognitive Load Assessment Framework

Example survey structure

COGNITIVE_LOAD_SURVEY = {
    "domain_complexity": {
        "question": "How well does the team understand the business domain?",
        "red_flag": "< 3"
    },

    "technology_breadth": {
        "question": "How many distinct technologies are maintained?",
        "red_flag": "> 5"
    },

    "dependency_count": {
        "question": "How many teams are required per sprint?",
        "red_flag": "> 3"
    }
}

This kind of lightweight operational telemetry is surprisingly valuable.

The Most Common Team Topologies Anti-Patterns

Most engineering organisations fail in recognisable ways.

The same patterns appear repeatedly.

Anti-Pattern 1: The Shared Services Team Bottleneck

Classic example

Shared DevOps Team

Responsible for:

• CI/CD
• Kubernetes
• Terraform
• Monitoring
• Networking
• Security
• Deployments

For every product team.

Result

Centralised dependency bottleneck

Symptoms:

• Long ticket queues
• Slow onboarding
• Deployment delays
• Platform burnout

The Real Cost

Shared services teams often become

Organisational rate limiters

Every engineering initiative slows behind them.

Better Model

Replace shared services with:

• Stream-aligned ownership
• Self-service platforms
• Enabling teams
• Platform-as-product

Anti-Pattern 2: Platform Teams Without a Defined Interface

Many platform teams say

"We provide Kubernetes."

But what does that actually mean operationally?

Healthy platforms define:

• APIs
• Golden paths
• Support models
• Service expectations
• Onboarding flows

Without interfaces

Platform becomes tribal knowledge.

Anti-Pattern 3: Enabling Teams That Never Stop Enabling

Enabling teams should create independence.

Not permanent dependency.

Danger signs:

• Teams require constant coaching forever
• Knowledge transfer never completes
• Enablement becomes embedded implementation

At that point the enabling team has failed structurally.

Anti-Pattern 4: Cognitive Load Mismatches

This is one of the most damaging failure modes.

Teams own too much simultaneously:

• Multiple languages
• Multiple databases
• Infrastructure
• Security
• CI/CD
• ML systems
• Distributed systems complexity

Eventually

Incident frequency rises
Delivery speed drops
Burnout accelerates

Measuring Cognitive Load

Indicators include

Cognitive overload is usually visible before collapse occurs.

Planning a Topology Change

Topology redesign is organisational surgery.

Done poorly, it creates chaos.

Done carefully, it dramatically improves flow.

Step 1: Identify Friction Points

Start with:

• Deployment delays
• Dependency bottlenecks
• Ticket queues
• Incident ownership confusion
• Platform dissatisfaction

Map flow disruptions explicitly.

Step 2: Reduce Team Dependencies

Optimise for

Independent delivery capability

Dependency reduction is usually the highest-ROI organisational improvement.

Step 3: Define Platform Interfaces

Every platform capability should answer:

• Who uses this?
• How is it consumed?
• Is it self-service?
• What are support expectations?

Step 4: Transition Gradually

Never reorganise everything simultaneously.

Recommended approach

Pilot topology
↓
Measure outcomes
↓
Expand incrementally

Organisational stability matters.

Measuring the Impact

Topology changes should produce measurable improvements.

Delivery Metrics

Track:

These align closely with DORA metrics.

Cognitive Load Surveys

Run quarterly.

Example

if red_flags >= 3:
    print("Urgent restructuring required")

Even lightweight surveys reveal structural problems surprisingly well.

Platform Satisfaction Scores

Ask stream-aligned teams

How frictionless is the platform?

This single question often exposes platform dysfunction rapidly.

Example Topology Transformation

Before

Developers
↓
Shared DevOps Team
↓
Infrastructure Team
↓
Security Team

Heavy coordination overhead.

Slow deployments.

Unclear ownership.

After

Stream-Aligned Teams
        ↓
Self-Service Platform
        ↓
Enabling Teams

Much faster flow.

Reduced dependencies.

Improved operational autonomy.

Common Mistakes During Team Topologies Adoption

Mistake 1: Renaming Teams Without Changing Responsibilities

Changing titles changes nothing operationally.

Mistake 2: Treating Platform Teams as Infrastructure Operations

Platform teams should optimise developer experience.

Not merely manage Kubernetes clusters.

Mistake 3: Ignoring Cognitive Load

More ownership is not always better.

Mistake 4: Measuring Utilisation Instead of Flow

Highly utilised teams often create slower organisations overall.

Flow efficiency matters more.

Recommended Organisational Architecture

Healthy modern engineering organisations increasingly resemble

Stream-Aligned Teams
        ↓
Platform-as-a-Service
        ↓
Enabling Teams
        ↓
Specialist Subsystem Teams

This structure scales operationally far better than traditional siloed models.

Team Topologies matters because software delivery problems are rarely just technical.

They are organisational.

The framework gives engineering leaders a practical vocabulary for understanding why certain DevOps transformations stall despite heavy investment in tooling and automation.

The most successful organisations consistently optimise for.

Fast flow
Low cognitive load
Clear ownership
Self-service platforms
Minimal dependencies

And those outcomes emerge not from organisational theory alone, but from deliberate topology design.

Because ultimately:

The architecture of your systems
reflects the architecture of your teams.

Always

Cloud security has seven structural contradictions. Every vendor treats them as trade-offs — improve one side, accept the other gets worse. TRIZ says trade-offs are engineering failures. Contradictions can be resolved. All seven resolved to the same architecture.

Every cloud security tool makes trade-offs:

• “We give you flexibility, but you’ll get more misconfigurations.”
• “We check before deployment, but it slows your engineers down.”
• “We scan continuously, but the results aren’t reproducible.”

Trade-offs feel reasonable. They’re not. They’re engineering failures — situations where improving one property worsens another because the framing of the problem is wrong.

There’s a methodology — 80 years old, derived from analyzing 200,000 patents — that says: don’t trade off. Resolve the contradiction. Keep both properties. The trick is splitting what was previously one thing into two — one that keeps the desirable property, one that absorbs the opposite.

I applied that methodology to cloud security. Seven contradictions were resolved to produce the architecture. Every contradiction resolved to the same three components. That convergence is the validation and the reason the resulting product is 1,030 lines of code that didn’t need to be rewritten.

Contradictions vs trade-offs

The distinction matters:

A trade-off accepts the framing. A resolution changes the framing. The methodology — TRIZ, by Genrich Altshuller — provides the discipline for finding which framing change resolves which contradiction.

The seven contradictions

Four months of analysis before writing code produced seven structural contradictions in cloud security. Each is a pair of desirable properties that the industry treats as mutually exclusive:

1. Flexibility vs Safety

We want engineers to build anything. But more flexibility produces more misconfigurations.

What every tool does: Add a scanner with a checklist. The checklist grows. Flexibility doesn’t shrink. The contradiction persists.

Resolution: Configuration stays flexible — Terraform, CDK, Pulumi can produce anything. The result is evaluated against invariants. Flexibility lives in the authoring. Safety lives in the evaluation. They’re separated.

2. Speed vs Correctness

We want engineers to ship fast. But fast shipping produces insecure configurations.

What every tool does: Add another CI check. Engineers learn to bypass with // skipcq and nosec. The check becomes a speed bump, not a safety net.

Resolution: The invariant evaluation runs in milliseconds. The engineer’s velocity is unaffected. The security architect writes the control once. Every subsequent evaluation is automatic. Speed and correctness operate on different clocks — neither blocks the other.

3. Decentralization vs Control

We want decentralized ownership (each team manages their own infrastructure). But decentralization produces inconsistency.

What every tool does: Add a central policy registry. The registry becomes the bottleneck teams route around.

Resolution: The invariant catalog is centrally declared (one canonical set of controls). The snapshots are decentrally produced (each team collects their own). The evaluation runs at the edge — wherever the snapshot is. Central authority over WHAT must hold. Decentralized responsibility for collecting evidence.

4. Human Judgment vs Reliability

We want human contextual judgment (this role needs broad permissions for the migration). But human judgment is inconsistent and irreproducible.

What every tool does: Add severity scores and ML-based triage. The ranking is opaque. The queue is unchanged. The human still decides.

Resolution: The judgment goes into the invariant when it’s authored — the security engineer encodes “PHI buckets must never be reachable by anonymous principals” once. Subsequent evaluations are mechanical. Zero judgment at evaluation time. The judgment was upstream, in the control definition. The evaluation is downstream, deterministic.

5. Expressiveness vs Complexity

We want expressive IaC (conditional resources, dynamic blocks, modules calling modules). But expressiveness produces complexity where errors hide.

What every tool does: Add a static analyzer for the IaC source. The analyzer can’t see what the IaC produces at apply-time — it analyzes the source, not the result.

Resolution: Evaluate the PRODUCED STATE, not the source code. The snapshot is the JSON representation of what Terraform/CDK/Pulumi produced after plan or apply. The IaC source can be as expressive as needed. The snapshot reduces all that expressiveness to typed facts the evaluator can read. Expressiveness lives in the source. Verifiability lives in the snapshot.

6. Dynamic Systems vs Stable Security

We want dynamic infrastructure (auto-scaling, ephemeral, managed services). But dynamic infrastructure breaks static security assumptions.

What every tool does: Make the security controls dynamic too — continuous scanning, runtime agents, real-time detection. Trades adaptability/predictability for responsiveness/reproducibility. The new contradiction is worse: same infrastructure, different results on different days.

Resolution: Keep the controls STATIC. Make the OBSERVATIONS dynamic. The invariant (“anonymous users must not reach PHI data”) doesn’t change when the infrastructure changes. The snapshot captures the infrastructure at a point in time. The evaluation reruns the static invariant against the dynamic snapshot. Deterministic, reproducible, composable.

This is the most consequential resolution in the set — and the only one where the textbook TRIZ principle (Dynamization — make the static thing dynamic) was INVERTED. Every vendor followed the textbook. The inversion produced the opposite architecture — and it’s the reason the product is deterministic where competitors aren’t.

7. Granular Permissions vs Manageability

We want fine-grained IAM permissions (least privilege). But 17,000 IAM actions produce an unmanageable rule set.

What every tool does: Add a policy generator. Generated policies are accurate today, stale tomorrow. The complexity moves from “write the policy” to “maintain the generator.”

Resolution: Humans declare role intent at the category level (“this is a read-only data role”). The control catalog encodes which permission patterns match which intent. The 17,000 IAM actions stay fine-grained — the manageability lives at the intent layer above them. An intermediary between human-readable intent and machine-readable permissions.

The four physical contradictions underneath

Underneath the seven technical contradictions sit four deeper ones — statements where a single thing must have opposite properties:

Every resolution has the same shape: split the thing that was previously one into two. One piece keeps the desirable property. The other absorbs the opposite. The split happens at a different point each time (source vs result, intent vs enforcement, control vs observation) but the move is the same: segmentation.

The convergence

The seven contradictions resolved and kept landing on the same three components:

The three components are:

1. A fixed declarative artifact that states a property that must hold → the invariant (YAML control).
2. A mutable observational artifact that captures the world at a point in time → the snapshot (JSON observation).
3. A deterministic evaluator that runs the first against the second → the engine (CEL predicate evaluation).

Resolving the seven contradictions shaped the architecture.

The convergence is the validation. If the seven contradictions had resolved to seven different architectures, the analysis would have decomposed the problem into seven sub-problems but missed the structural one. The convergence proves the seven are symptoms of one shape underneath and the three-component architecture is that shape.

The nine inventive principles

The TRIZ contradiction matrix suggested specific principles for each contradiction pair. Nine principles did work across all seven:

The same principles appearing across multiple contradictions is the signature of an architecture with high internal cohesion. The same moves do work across different problem dimensions — because the problem dimensions are symptoms of one underlying structure.

What the industry accepts as trade-offs

Every item is a trade-off the industry accepts. Every item is a contradiction that can be resolved:

Seven trade-offs the industry treats as laws of nature. Seven contradictions that are resolvable with known techniques. The techniques are 80 years old. The application to cloud security is new.

Why convergence matters for builders

If you’re facing multiple contradictions in your own domain and each one seems to need a different solution, you haven’t found the structural contradiction yet. The surface contradictions are symptoms. The structural contradiction is underneath them.

The test: do your resolutions converge?

If seven contradictions resolve to seven different architectures, you’ve decomposed the problem into seven sub-problems. Each sub-solution adds a component. The result is a complex system with seven moving parts.

If seven contradictions resolve to one architecture, you’ve found the shape underneath. The single architecture is simpler than seven sub-solutions. It’s more coherent. And it’s more likely to be correct — because the convergence itself is evidence that you’ve identified the structural problem, not just the symptoms.

Four months of analysis. Seven contradictions named. Nine inventive principles applied. One architecture produced. 1,030 lines of kernel code. No rewrites.

The thinking was the foundation. The code was the proof.

The three-component architecture — invariant (2,650 YAML controls), snapshot (obs.v0.1 JSON), evaluator (1,030-line CEL predicate engine) — is implemented in Stave, an open-source Risk Reasoner. Seven contradictions resolved. One architecture. Every conclusion deterministic, traceable, and provable. Try it: bash examples/demo-ai-security/run.sh

You click “Sign in with Google” on GitHub. Seconds later, you are in. No new account. No new password.

That felt simple. The system behind it is not.

This article breaks down the four protocols that power modern identity management: SSO, SAML, OIDC, and SCIM. You will understand what each one does, where they differ, and how they work together in real companies like Netflix and Airbnb.

The Problem These Protocols Solve

Before SSO, every app had its own login database. A new employee joining a company needed separate accounts in Gmail, Slack, Jira, Salesforce, and every other tool. IT teams created each account by hand. When someone left, accounts often lingered for weeks, open to misuse.

Three problems emerged:

• Users carried dozens of passwords, and reused them
• IT spent hours on account creation and resets
• Every separate login system was a separate attack surface

SSO solves this by centralizing authentication. You log in once to a trusted Identity Provider (IDP) and every other app trusts that login. One credential. One place to enforce MFA. One place to revoke access.

But SSO is not a single technology. It is a goal. SAML, OIDC, and SCIM are the tools that achieve it.

The Three Main Players in Any SSO Flow

Before going into protocols, know these three roles:

User: The person trying to access a service.

Identity Provider (IDP): The system that verifies the user’s identity. Examples: Okta, Azure AD, Google Workspace.

Service Provider (SP): The application the user wants to access. Examples: Salesforce, GitHub, Slack.

The IDP and SP are separate systems. They trust each other through a formal agreement called federation. Federation lets your company’s IDP issue a kind of digital passport, and every connected app checks that passport at the door.

SAML: The Enterprise Veteran

SAML stands for Security Assertion Markup Language. It is an open standard that has powered enterprise SSO since 2002.

Here is the step-by-step SAML flow:

1. You try to access Salesforce (the Service Provider)
2. Salesforce redirects you to your IDP (say, Okta)
3. Okta asks for your credentials and verifies them, including MFA
4. Okta generates a SAML Assertion, an XML document containing your identity, roles, and group memberships
5. Okta sends that assertion back to Salesforce
6. Salesforce verifies the IDP’s digital signature on the assertion and grants access

The assertion is the key artifact. It carries signed proof of who you are and what roles you hold. Salesforce does not store your password. It trusts Okta’s signature.

Where SAML excels:

• Legacy enterprise apps (Salesforce, Workday, ServiceNow)
• Organizations with strict compliance requirements (healthcare, government)
• Web browser-based SSO flows

Where SAML struggles:

• Mobile apps, which do not handle XML-based browser redirects well
• APIs and microservices that prefer JSON
• Modern single-page applications

Real example: A hospital network uses SAML to give doctors access to patient record systems, billing tools, and scheduling software with one login. Auditors get a single log of every access event. SAML’s verbose XML is worth the overhead when the data is sensitive and regulated.

OIDC: The Modern API-Friendly Option

OpenID Connect, or OIDC, is built on top of OAuth 2.0. OAuth handles authorization (what an app is allowed to do on your behalf). OIDC adds the missing authentication layer (who you actually are).

When you click “Sign in with Google” on GitHub, you are using OIDC.

Here is the flow:

1. You click “Sign in with Google” on GitHub
2. GitHub redirects you to Google’s authorization server
3. Google asks for your credentials
4. Google sends back two tokens: an Access Token and an ID Token
5. The ID Token is a JWT (JSON Web Token) signed by Google, containing your identity
6. GitHub reads the JWT, verifies Google’s signature, and logs you in

The JWT looks like this (decoded):

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "email": "[email protected]",
  "iss": "https://accounts.google.com",
  "exp": 1716560000
}

This is lightweight, JSON-based, and works seamlessly in mobile apps, SPAs, and API calls.

SAML vs OIDC at a glance:

Real example: Spotify’s mobile app uses OIDC when you log in with Facebook. The app receives a JWT, verifies it, and creates your session without ever touching Facebook’s password system.

SCIM: The Account Lifecycle Manager

SAML and OIDC handle authentication. They answer: who is this user?

SCIM (System for Cross-domain Identity Management) answers a different question: does this user’s account exist in the first place, and does it have the right attributes?

SCIM is a REST API specification. If your app implements SCIM endpoints, an IDP like Okta or Azure AD can automatically:

• Create accounts when someone joins
• Update attributes when someone changes teams
• Deactivate accounts when someone leaves

Here is what SCIM looks like in practice:

Create a new user (IDP calls your app):

POST /scim/v2/Users
{
  "userName": "[email protected]",
  "name": { "givenName": "Jane", "familyName": "Doe" },
  "department": "Engineering",
  "active": true
}

Deactivate a user on departure:

PATCH /scim/v2/Users/12345
{
  "Operations": [{ "op": "replace", "path": "active", "value": false }]
}

When Jane joins the company, her IDP account triggers SCIM calls to Slack, Zoom, GitHub, and Jira. Her accounts appear before her first day. When Jane leaves, one deactivation in the IDP removes access everywhere within minutes.

Real example: Netflix built an internal “People Service” that ingests identity data from Workday and Azure AD, then distributes it to hundreds of internal tools via SCIM and internal APIs. Without this, onboarding a new engineer would require tickets to a dozen different teams.

How the Three Protocols Work Together

These are not competing standards. Each solves a different layer of the same problem.

HR System
    |
    | (triggers onboarding event)
    v
Identity Provider (Okta / Azure AD)
    |
    |-- SCIM --> Creates accounts in Slack, GitHub, Zoom, Salesforce
    |
    |-- SAML --> Authenticates users in legacy enterprise apps
    |
    |-- OIDC --> Authenticates users in modern apps and APIs

A concrete scenario:

1. A new engineer joins. HR updates their record.
2. Azure AD receives the event and uses SCIM to create accounts in GitHub, Slack, and Jira with the correct team permissions overnight.
3. The next morning, she logs into Azure AD once.
4. Azure AD uses OIDC to authenticate her into the internal developer portal.
5. Azure AD uses SAML to authenticate her into the legacy finance system.
6. She accesses everything without logging in again.
7. Six months later, she leaves. Azure AD deactivates her account. SCIM removes her access from every connected app within minutes. SAML and OIDC stop issuing tokens for her identity.

The Pros and Cons

SSO (the goal):

Pros:

• One set of credentials for all apps
• Centralized MFA enforcement
• Single audit log for access events
• Faster onboarding and offboarding

Cons:

• If the IDP goes down, users lose access to everything
• Requires careful configuration between IDP and each service provider
• Single point of compromise if the IDP is breached without strong MFA

SAML:

Pros:

• Mature, battle-tested in enterprises
• Carries rich attributes (roles, groups, departments)
• Strong support in legacy enterprise apps

Cons:

• XML is verbose and complex to debug
• Poor fit for mobile apps and APIs
• Implementation errors (like signature validation mistakes) are a common source of vulnerabilities

OIDC:

Pros:

• Lightweight JSON tokens
• Works everywhere: web, mobile, APIs
• Built on OAuth 2.0, which developers already know

Cons:

• JWT misconfiguration (like skipping signature validation) creates security holes
• Token expiry and refresh logic requires careful handling

SCIM:

Pros:

• Eliminates manual account management
• Reduces orphaned accounts (a major security risk)
• Standardized, so IDPs support it out of the box

Cons:

• Not every app supports SCIM endpoints
• Centralizing SCIM in a sync service adds architectural complexity
• Debugging sync failures across many apps is non-trivial

Where This Fits in the Bigger Picture: IAM

SSO, SAML, OIDC, and SCIM are components of a broader discipline called Identity and Access Management (IAM).

IAM covers:

• Authentication (AuthN): Proving who you are. SAML, OIDC, MFA.
• Authorization (AuthZ): Controlling what you can do. RBAC, ABAC, policy engines like OPA.
• Provisioning: Managing account lifecycles. SCIM.
• Federation: Trust between organizations. SAML, OIDC across org boundaries.

A practical distinction worth knowing: AWS IAM is Amazon’s system for controlling access to AWS resources (S3, EC2, Lambda). It is not a general enterprise IDP. Most companies use Okta or Azure AD as their central IDP and connect to AWS through federation and role mappings.

When a developer logs into AWS through Okta SSO, Okta authenticates them (via SAML or OIDC) and passes their identity to AWS IAM, which then decides what resources they can access.

A Real Security Consideration: The SSO Risk Trade-Off

SSO reduces password sprawl and improves user experience. But it concentrates risk.

If an attacker compromises an employee’s IDP credentials and MFA, they gain access to every federated application at once. This is why:

• MFA on the IDP is not optional, it is the primary defense layer
• Conditional access policies (blocking logins from unrecognized devices or locations) are critical
• Session timeouts should be enforced at the IDP level
• Privileged accounts should use hardware security keys (FIDO2), not TOTP codes

The 2023 MGM Resorts breach reportedly started with social engineering an IT help desk into resetting an Okta account. The attacker then moved laterally across MGM’s systems using the SSO trust relationships. SSO amplified the blast radius of a single credential compromise.

The lesson: SSO is more secure than password sprawl when configured correctly. The IDP is the crown jewel. Protect it accordingly.

Summary

• SAML handles authentication for enterprise web apps using XML assertions. Mature, verbose, and essential for legacy systems.
• OIDC handles authentication for modern apps and APIs using lightweight JSON tokens. Built on OAuth 2.0.
• SCIM handles account lifecycle management. It creates, updates, and removes user accounts automatically across all your apps.
• SSO is the goal. SAML and OIDC are the protocols that deliver it. SCIM keeps the underlying accounts in sync.
• IAM is the full framework. SSO is one piece of it.

If you are building a product today, start with OIDC for authentication and implement SCIM endpoints if you want enterprise customers (they will ask for it). If you are connecting to legacy enterprise systems, SAML support is non-negotiable.

Found this useful? Share it with your team. If you want a deeper breakdown of OAuth 2.0 flows, JWT security, or RBAC versus ABAC authorization models, drop a comment below.

The landscape of web development is shifting. In 2026, the boundary between the client and the server has all but vanished. Next.js 16 Server Actions represent the pinnacle of this evolution, allowing developers to write mutations that are as simple as calling a local function, yet powerful enough to handle complex full-stack workflows.

By Muhammad Arslan

Senior Full Stack Engineer & Node.js Specialist

In this guide, we will move beyond the basics. We’ll explore how to leverage React 19 Hooks (useActionState, useOptimistic) and Next.js 16 internals to build forms that are not only type-safe and secure but also provide a “zero-latency” experience for users.

1. The Paradigm Shift: From APIs to Actions

For years, the standard way to handle form submissions in React was:

1. Create an API route (e.g., /api/submit).
2. Manage loading, error, and data states with multiple useState hooks.
3. Manually fetch the endpoint on the client.
4. Handle response serialization and revalidation.

Server Actions eliminate this entire middle layer. They are asynchronous functions that run on the server, marked with the 'use server' directive. When you call an action, Next.js handles the POST request, serialization, and revalidation for you—automatically.

Comparison: Why the change matters

2. Managing Complex Form State with useActionState

React 19 introduced useActionState (replacing the experimental useFormState). It is the primary hook for handling the response of a Server Action within a form.

Instead of managing isLoading and error manually, useActionState consolidates your form lifecycle into a single, predictable state object.

// Optimized by Muhammad Arslan
import { useActionState } from 'react';
import { signUpAction } from './actions';

export default function SignUpForm() {
  const [state, formAction, isPending] = useActionState(signUpAction, { 
    success: false, 
    errors: {} 
  });

  return (
    <form action={formAction} className="glass-container">
      <input name="email" type="email" placeholder="Email" />
      {state.errors.email && <p className="text-red-500">{state.errors.email}</p>}

      <button disabled={isPending}>
        {isPending ? "Creating Account..." : "Sign Up"}
      </button>
    </form>
  );
}

3. Real-Time Feedback with useFormStatus

A common UX pitfall is the lack of feedback during submission. While useActionState gives you isPending, React 19 provides useFormStatus to help you create reusable UI components that “know” their parent form’s status without prop-drilling.

Important Note from Muhammad Arslan: useFormStatus must be used in a child component of the <form>.

// app/components/SubmitButton.tsx
'use client';
import { useFormStatus } from 'react-dom';

export function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <button 
      type="submit" 
      disabled={pending}
      className={`btn ${pending ? 'opacity-50 cursor-not-allowed' : ''}`}
    >
      {pending ? "Saving..." : "Save Changes"}
    </button>
  );
}

4. Zero-Latency UX with useOptimistic

Users hate waiting. Optimistic Updates allow you to show the result of an action before the server even responds. If the server fails, React automatically rolls back the UI to the previous state.

This pattern is essential for high-engagement features like chat messages or social likes.

'use client';
import { useOptimistic } from 'react';

export function CommentList({ initialComments }) {
  const [optimisticComments, addOptimisticComment] = useOptimistic(
    initialComments,
    (state, newComment: string) => [...state, { content: newComment, id: 'temp' }]
  );

  async function action(formData: FormData) {
    const content = formData.get('content') as string;
    addOptimisticComment(content); // Update UI instantly
    await postComment(formData);    // Run the actual Server Action
  }

  return (
    <div>
      {optimisticComments.map(c => <div key={c.id}>{c.content}</div>)}
      <form action={action}>
        <input name="content" required />
        <button type="submit">Post</button>
      </form>
    </div>
  );
}

5. The “Arslan Security Layer”: Zod + Server Actions

Never trust client-side data. Because Server Actions are just functions, they are vulnerable to malicious payloads if not properly gated. I recommend a “Validation-First” approach using Zod.

// app/actions.ts
'use server';

import { z } from 'zod';
import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

const schema = z.object({
  email: z.string().email(),
  username: z.string().min(3),
});

export async function updateUser(prevState: any, formData: FormData) {
  const validated = schema.safeParse(Object.fromEntries(formData.entries()));

  if (!validated.success) {
    return { errors: validated.error.flatten().fieldErrors };
  }

  // Pure server-side execution: Secrets are safe here
  await db.user.update({
    where: { id: process.env.CURRENT_USER_ID },
    data: validated.data,
  });

  revalidatePath('/profile');
  return { success: true };
}

6. Closing the Loop: Data Revalidation

One of the most powerful features of Server Actions is their integration with the Next.js Cache. By calling revalidatePath('/dashboard') or revalidateTag('user-data'), you tell Next.js to purge the cache and refetch the data for those specific segments.

This ensures that once your Server Action completes, the user sees the updated data immediately without a manual page refresh.

Conclusion: Why This Matters

Next.js 16 and React 19 have shifted the focus back to the server, but with the responsiveness of a client-side app. By mastering Server Actions, Zod validation, and Optimistic UI, you build applications that are:

1. More Secure: Sensitive logic never leaves the server.
2. Faster: Zero API boilerplate and instant UI feedback.
3. Resilient: Progressive enhancement ensures your forms work even on slow connections.

The web is evolving, and the server is once again the center of that evolution.

What’s your experience with React 19 hooks? Join the discussion and see more of my work at muhammadarslan.codes.

Enterprise application development in 2026 demands APIs that are not just functional, but resilient, blazingly fast, and capable of scaling seamlessly under heavy loads. While Laravel is often praised for its developer velocity and elegant syntax, scaling a Laravel API to support millions of requests requires deliberate architectural decisions and optimization strategies.

By Muhammad Arslan

Senior Full Stack Engineer, Node.js Specialist, & Laravel PHP Developer Consultant

As a Laravel PHP developer consultant and Node.js React full stack developer who has architected systems for global SaaS platforms, I have seen firsthand how easily standard MVC patterns can degrade in enterprise environments. This Laravel API development guide provides a deep-dive blueprint into advanced patterns, database optimizations, resilient queue processing, and security layers required to build world-class enterprise services.

Table of Contents

1. Architecting Beyond standard MVC: Services and Repositories
2. Laravel Eloquent ORM Advanced Techniques
3. Resilient Background Processing with Queues
4. Enterprise-Grade Security & API Versioning
5. Laravel vs Node.js Comparison: Architectural Decisions
6. Conclusion & Enterprise CTA

1. Architecting Beyond Standard MVC: Services and Repositories

In standard Laravel applications, controllers often accumulate business logic, database queries, and data validation. For enterprise-grade systems, this creates tight coupling and makes writing robust unit tests extremely difficult.

To build a modular system, we decouple the components by introducing a Service Layer to handle business logic and a Repository Layer to isolate database operations.

┌─────────────────┐      ┌───────────────┐      ┌─────────────────┐      ┌──────────────┐
│   Controller    │ ───> │ Service Layer │ ───> │ Repository Layer│ ───> │  Database /  │
│ (HTTP Lifecycle)│      │(Business Logic│      │(Data Access Lyr)│      │  Data Store  │
└─────────────────┘      └───────────────┘      └─────────────────┘      └──────────────┘

The Service Pattern in Action

The Controller should only be responsible for:

1. Validating the incoming request payloads.
2. Invoking the appropriate Service class.
3. Returning the serialized HTTP response.

Here is an enterprise implementation for handling user registrations:

// app/Http/Controllers/Api/v1/UserController.php
namespace AppHttpControllersApiv1;

use AppHttpControllersController;
use AppHttpRequestsv1RegisterUserRequest;
use AppHttpResourcesv1UserResource;
use AppServicesUserRegistrationService;
use IlluminateHttpJsonResponse;
use SymfonyComponentHttpFoundationResponse;

class UserController extends Controller
{
    protected UserRegistrationService $registrationService;

    public function __construct(UserRegistrationService $registrationService)
    {
        $this->registrationService = $registrationService;
    }

    public function register(RegisterUserRequest $request): JsonResponse
    {
        // Controller is thin: validates request via FormRequest and calls service
        $user = $this->registrationService->registerUser($request->validated());

        return (new UserResource($user))
            ->response()
            ->setStatusCode(Response::HTTP_CREATED);
    }
}

By keeping the controller thin, we can easily change our HTTP layer or write CLI commands that execute the exact same registration flow by injecting the UserRegistrationService.

Implementing the Repository Layer

The repository layer abstracts database operations, allowing the service to remain agnostic of the database system (Eloquent, Query Builder, or external APIs).

// app/Repositories/Contracts/UserRepositoryInterface.php
namespace AppRepositoriesContracts;

use AppModelsUser;

interface UserRepositoryInterface
{
    public function create(array $data): User;
    public function findByEmail(string $email): ?User;
}

// app/Repositories/Eloquent/UserRepository.php
namespace AppRepositoriesEloquent;

use AppModelsUser;
use AppRepositoriesContractsUserRepositoryInterface;

class UserRepository implements UserRepositoryInterface
{
    public function create(array $data): User
    {
        return User::create($data);
    }

    public function findByEmail(string $email): ?User
    {
        return User::where('email', $email)->first();
    }
}

We bind this interface inside a service provider to enable dependency injection:

// app/Providers/RepositoryServiceProvider.php
namespace AppProviders;

use IlluminateSupportServiceProvider;
use AppRepositoriesContractsUserRepositoryInterface;
use AppRepositoriesEloquentUserRepository;

class RepositoryServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->bind(UserRepositoryInterface::class, UserRepository::class);
    }
}

Now, the UserRegistrationService can consume the interface, making it completely testable via mocks:

// app/Services/UserRegistrationService.php
namespace AppServices;

use AppModelsUser;
use AppRepositoriesContractsUserRepositoryInterface;
use IlluminateSupportFacadesDB;
use IlluminateSupportFacadesLog;
use Exception;

class UserRegistrationService
{
    protected UserRepositoryInterface $userRepository;

    public function __construct(UserRepositoryInterface $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function registerUser(array $data): User
    {
        DB::beginTransaction();

        try {
            $user = $this->userRepository->create([
                'name' => $data['name'],
                'email' => $data['email'],
                'password' => bcrypt($data['password']),
            ]);

            // Fire events, dispatch jobs, connect third-party APIs
            event(new AppEventsUserRegistered($user));

            DB::commit();
            return $user;
        } catch (Exception $e) {
            DB::rollBack();
            Log::error('Registration failure: ' . $e->getMessage(), ['data' => $data]);
            throw new Exception('User registration failed. Please try again.');
        }
    }
}

2. Laravel Eloquent ORM Advanced Techniques

Database latency is the most common performance bottleneck in modern web APIs. Eloquent is incredibly powerful, but it makes it easy to run unoptimized queries. This section explores Laravel Eloquent ORM advanced techniques to eliminate query overhead.

Preventing the N+1 Query Problem

The N+1 query problem occurs when you fetch a parent model and then execute an additional query for each child model. For a list of 100 posts, this results in 101 queries.

// ❌ BAD: Triggers N+1 queries
$books = Book::all();
foreach ($books as $book) {
    echo $book->author->name; // Executed for each book
}

To resolve this, we leverage Eager Loading to fetch all relations in a single, efficient query using with():

// ✅ GOOD: Triggers only 2 queries
$books = Book::with('author')->get();

In enterprise APIs, you should strictly enforce database safety during development. Laravel allows you to disable lazy loading entirely in your bootstrap environment:

// app/Providers/AppServiceProvider.php
use IlluminateDatabaseEloquentModel;

public function boot(): void
{
    Model::preventLazyLoading(! $this->app->isProduction());
}

This ensures that any accidentally introduced N+1 query throws an exception immediately in staging or local environments.

Highly Efficient Pagination: Cursor vs Offset

Standard Laravel offset-based pagination (paginate()) generates queries containing OFFSET values:

SELECT * FROM orders LIMIT 15 OFFSET 10000;

As the offset increases, database performance degrades significantly because the database engine must scan all previous records before returning the requested page.

For high-volume APIs (such as infinity-scroll clients built by a Senior React developer consultant), use Cursor Pagination via cursorPaginate(). Cursor pagination uses a “cursor” string containing the ID of the last item in the page and queries against indexing directly:

SELECT * FROM orders WHERE id > 10000 ORDER BY id ASC LIMIT 15;

// ✅ Cursor pagination for ultra-fast large dataset queries
$orders = Order::orderBy('id', 'desc')->cursorPaginate(25);

Optimizing Serialization: Eloquent API Resources

Never return raw Eloquent models from your API controllers. Models contain internal attributes, hidden fields, and database structures that should not be exposed. Always transform payloads with API Resources.

// app/Http/Resources/v1/UserResource.php
namespace AppHttpResourcesv1;

use IlluminateHttpRequest;
use IlluminateHttpResourcesJsonJsonResource;

class UserResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'email' => $this->email,
            'role' => $this->role,
            'registered_at' => $this->created_at->toIso8601String(),
            // Load relations conditionally only if eager loaded
            'profile' => new ProfileResource($this->whenLoaded('profile')),
        ];
    }
}

Using $this->whenLoaded() prevents the API resource from triggering N+1 queries if the relationship wasn’t intentionally eager-loaded.

3. Resilient Background Processing with Queues

An API should return a response to the user within milliseconds. Long-running tasks, such as sending emails, processing file uploads, or interacting with third-party billing providers, must be deferred to the background.

Implementing Laravel queue jobs and background processing is crucial for maintaining high responsiveness.

Client ───(Request)───> [ Laravel API ] ───(Dispatch Job)───> [ Redis Queue Store ]
                               │                                      │
Client <───(Response)─── [200 OK Response]                            └──> [ Queue Workers ]

Configuring Redis and Supervisor for Maximum Reliability

In enterprise systems, avoid the standard database queue driver. Use Redis for sub-millisecond execution times.

First, update your environment configuration:

QUEUE_CONNECTION=redis

To ensure your queue workers run continuously in production, configure Supervisor on your hosting environments. Create a worker configuration:

# /etc/supervisor/conf.d/laravel-worker.conf
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/my-api/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/my-api/storage/logs/worker.log
stopwaitsecs=3600

Building an Idempotent, High-Performance Job

Every queued job must be idempotent, meaning that running the same job multiple times has the exact same side effect. If a network interruption occurs and a job is retried, it must not execute duplicate logic (e.g., charging a customer twice).

Here is a resilient job implementation:

// app/Jobs/ProcessInvoicePayment.php
namespace AppJobs;

use AppModelsInvoice;
use AppServicesPaymentGatewayService;
use IlluminateBusQueueable;
use IlluminateContractsQueueShouldQueue;
use IlluminateFoundationBusDispatchable;
use IlluminateQueueInteractsWithQueue;
use IlluminateQueueSerializesModels;
use IlluminateSupport - FacadesLog;
use Exception;

class ProcessInvoicePayment implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    protected Invoice $invoice;
    public int $tries = 5;
    public int $backoff = 30; // Wait 30 seconds before retrying

    public function __construct(Invoice $invoice)
    {
        $this->invoice = $invoice;
    }

    public function handle(PaymentGatewayService $paymentService): void
    {
        // 1. Idempotency Check: Prevent duplicate payment processing
        if ($this->invoice->status === 'paid') {
            Log::info("Invoice {$this->invoice->id} is already paid. Skipping.");
            return;
        }

        try {
            $paymentService->charge([
                'amount' => $this->invoice->total,
                'email' => $this->invoice->user->email,
                'invoice_id' => $this->invoice->id,
            ]);

            $this->invoice->update(['status' => 'paid', 'paid_at' => now()]);
        } catch (Exception $e) {
            Log::error("Payment failed for invoice {$this->invoice->id}: " . $e->getMessage());
            throw $e; // Throw exception to trigger queue retry/backoff
        }
    }

    public function failed(Exception $exception): void
    {
        // Execute failure logic, alert administrators, or update model
        $this->invoice->update(['status' => 'failed_payment']);
        Log::critical("Invoice {$this->invoice->id} failed permanently after multiple retries.");
    }
}

4. Enterprise-Grade Security & API Versioning

An enterprise API must protect sensitive data from malicious actors and provide a reliable, backwards-compatible upgrade path for consumers.

Secure Request Gating using Form Requests

Never validate data directly inside your controllers. Use Form Requests to isolate validation rules, clean up input, and verify authorization:

// app/Http/Requests/v1/StoreBookRequest.php
namespace AppHttpRequestsv1;

use IlluminateFoundationHttpFormRequest;

class StoreBookRequest extends FormRequest
{
    public function authorize(): bool
    {
        // Secure gating check
        return $this->user()->can('create', Book::class);
    }

    public function rules(): array
    {
        return [
            'title' => 'required|string|max:255',
            'isbn' => 'required|string|unique:books,isbn',
            'author_id' => 'required|exists:authors,id',
            'published_year' => 'required|integer|between:1000,' . date('Y'),
        ];
    }
}

Resilient API Versioning Strategy

For enterprise environments, API payloads change frequently. To prevent breaking client applications, use a URL-based versioning strategy coupled with route groups:

// routes/api.php
use IlluminateSupportFacadesRoute;

Route::prefix('v1')
    ->namespace('AppHttpControllersApiv1')
    ->group(base_path('routes/api_v1.php'));

Route::prefix('v2')
    ->namespace('AppHttpControllersApiv2')
    ->group(base_path('routes/api_v2.php'));

This keeps your routing files clean, maintainable, and prevents namespace pollution.

5. Laravel vs Node.js Comparison: Architectural Decisions

A frequent question for technology leaders is whether to build high-scale backends using PHP/Laravel or Node.js. As an engineer highly proficient in both ecosystems, my Laravel vs Node.js comparison focuses on the specific strengths of each language.

┌───────────────────────────────────────┐   ┌───────────────────────────────────────┐
│              PHP Laravel              │   │               Node.js                 │
├───────────────────────────────────────┤   ├───────────────────────────────────────┤
│ • Excellent multi-layered architecture│   │ • Highly asynchronous event loop      │
│ • Elegant Eloquent ORM / Schema   │   │ • Sub-millisecond raw performance     │
│ • Fully-featured queue ecosystem      │   │ • Native WebSocket (real-time) support│
│ • Perfect for complex business systems│   │ • Great for high-concurrency and I/O  │
└───────────────────────────────────────┘   └───────────────────────────────────────┘

Comparison Matrix

The Hybrid Enterprise Standard

In 2026, the modern standard is not an “either-or” decision. Large-scale enterprise systems achieve optimal performance through Hybrid Architectures:

1. Laravel Backend: Serves as the primary transactional system, managing complex enterprise business logic, relational databases (PostgreSQL/MySQL), authorization, background queues, and billing systems.
2. Node.js Microservices: Handle real-time WebSockets, streaming analytics, highly concurrent file parsing, and I/O-intensive gateway services.
3. React/Next.js Client: Connects seamlessly to both backends, using Laravel for transactional API actions and Node.js for real-time dashboard subscriptions.

Interested in exploring full-stack React architectures? See my guide on Mastering React Hooks and React Server Components.

6. Conclusion & Enterprise CTA

Building a scalable, production-ready enterprise API requires moving past default frameworks. By implementing a strictly decoupled Service-Repository Architecture, enforcing preventative ORM strategies, leveraging highly resilient Redis queues via Supervisor, and utilizing structured Form Requests and API versioning, you lay a technical foundation capable of scaling to millions of users.

Need a Technical Partner to Scale Your Architecture?

Whether you require a highly secure transactional REST API, an optimized database schema to eliminate latency, or are looking to migrate from a legacy system to a modern microservices architecture, my experience as a Laravel PHP developer consultant and Node.js React full stack developer is here to help.

Let’s discuss how we can scale your software infrastructure for global performance.

👉 Get in Touch for a Technical Consultation

Most Rust developers expect the pitch to hold: compile to WebAssembly, ship to the browser, no C required. Add the wasm32-unknown-unknown target, run wasm-pack build, and you’re done.

Then you try it on a real project. Four traps, none of them in the getting-started docs: a deprecated allocator with a memory leak, hidden C dependencies scattered through the ecosystem, a random number crate that silently misbehaves, and bundle sizes that balloon from Emscripten glue.

The Problem with “Just Use Rust”

The core appeal of Rust for WASM is real: no garbage collector, predictable memory, and — in theory — no need for the C/C++ toolchain that browser WASM has historically required.

But the Rust crate ecosystem has C dependencies scattered throughout it, often invisible until compile time. A project that builds fine on Linux will fail on wasm32-unknown-unknown because three levels down in the dependency tree, something links to libz, openssl, or a system RNG.

When I built chem-wasm-lens — a molecular analysis library for the browser — I needed to stay completely C-free. The alternative, RDKit (the standard C++ cheminformatics toolkit), compiles to a ~40MB WASM bundle via Emscripten. My target was under 200KB gzipped. Getting there meant systematically hunting down every C dependency.

The Allocator Story

Every WASM tutorial from a few years ago recommended wee_alloc: a tiny allocator that shrank bundle size and was the default in wasm-pack new.

wee_alloc was archived in August 2025. It has a known memory leak and is no longer maintained. If you have it in an existing project, remove it:

# Cargo.toml — remove this line
wee_alloc = "0.4"

// lib.rs — remove these lines
#[global_allocator]
static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;

The current state of WASM allocators:

• Default (dlmalloc): Rust’s wasm32-unknown-unknown target uses dlmalloc as the default global allocator. It’s a pure Rust implementation — no C, no system calls. For most browser WASM projects, this is fine.
• lol_alloc: Written as a wee_alloc replacement. Smaller than dlmalloc, but the author documents it as not production-ready.
• talc: A newer allocator, benchmarked as smaller and faster than dlmalloc. Worth watching for size-critical projects.

For most projects: just use the default and move on. The allocator is no longer the interesting problem. The interesting problem is transitive C deps.

The Hidden C Dependency Tree

The most common wasm-pack build failure isn’t your code — it’s a crate three levels deep that silently links to C. The build error typically looks like:

error: failed to run custom build command for `openssl-sys v0.9.x`
  ...
  Could not find directory of OpenSSL installation.

Or for ring:

error: failed to run custom build command for `ring v0.17.x`
  ...
  the target `wasm32-unknown-unknown` is not supported

-sys crates are the signal. Any crate with a -sys suffix wraps a native library:

• openssl-sys — OpenSSL
• libz-sys — zlib
• bzip2-sys — libbz2
• libsqlite3-sys — SQLite
• ring — cryptography (C code for performance-critical paths)

You probably didn’t add any of these directly. reqwest pulls in openssl-sys by default. flate2 uses libz-sys by default. sqlx brings in libsqlite3-sys.

How to detect them:

cargo tree --target wasm32-unknown-unknown | grep "-sys"

Example output from a project using reqwest and flate2:

├── flate2 v1.0.x
│   └── libz-sys v1.1.x (*)       ← C dependency
├── reqwest v0.12.x
│   └── openssl-sys v0.9.x (*)    ← C dependency

Any -sys crate in the output is a potential blocker.

Common replacements:

Here’s what a typical fix looks like in Cargo.toml:

[dependencies]
# Before (pulls in openssl-sys):
# reqwest = "0.12"

# After (pure Rust TLS):
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls", "json"] }

# Before (uses libz-sys by default):
# flate2 = "1.0"

# After (pure Rust miniz backend):
flate2 = { version = "1.0", default-features = false, features = ["miniz"] }

The ring situation deserves a specific note. ring powers most TLS stacks in the Rust ecosystem, and it contains C code for performance-critical paths. On wasm32-unknown-unknown, it fails to compile.

For browser WASM, this is usually not a problem — the browser’s fetch API handles TLS transparently, so Rust code never touches it. For non-browser WASM runtimes (WASI, Wasmtime), look at RustCrypto crates, which provide pure Rust cryptographic primitives, or aws-lc-rs, which has better WASM support than ring.

The getrandom Footgun

Many crates need random numbers — UUID generation, HashMap initialization, cryptographic primitives. They all end up depending on getrandom.

On wasm32-unknown-unknown, getrandom doesn’t know where it is. The target name alone says nothing about whether you’re in a browser, a WASI runtime, or a bare-metal environment. Without explicit configuration, the build fails or panics at runtime, depending on the version.

First, find which version is in your tree:

cargo tree | grep getrandom

The fix depends on the version:

getrandom 0.2.x — add the js feature:

# Cargo.toml
[dependencies]
getrandom = { version = "0.2", features = ["js"] }

getrandom 0.3.x — feature flag plus a backend declaration:

In 0.3.x, getrandom introduced a “backend” model that separates feature flags from backend selection. Both are required:

# Cargo.toml
[dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }

# .cargo/config.toml
[target.wasm32-unknown-unknown]
rustflags = ["--cfg", "getrandom_backend="wasm_js""]

The transitive dependency trap. You can’t set feature flags for indirect dependencies directly. If uuid depends on getrandom and you don’t use getrandom yourself, you still need to declare it explicitly so Cargo’s feature unification propagates the flag:

[dependencies]
uuid = { version = "1", features = ["v4"] }
# Explicitly declare getrandom to force the js feature through the tree
getrandom = { version = "0.2", features = ["js"] }

The getrandom docs also recommend against enabling js/wasm_js in libraries — it breaks non-browser WASM builds. For a browser-only library like chem-wasm-lens, enabling it unconditionally is the right call, but the documentation buries this distinction.

Bundle Size

This is where C dependencies have their most visible cost.

C libraries compiled to WASM via Emscripten carry significant overhead: libc, libc++, a malloc implementation, and Emscripten runtime glue — regardless of how much of it you actually use. Tree shaking doesn’t cross the FFI boundary. The result:

• RDKit.js: ~40MB (Emscripten-compiled C++ cheminformatics)
• OpenSSL compiled to WASM: ~1–2MB just for the crypto primitives

Pure Rust compiles lean. chem-wasm-lens ships at 411KB uncompressed, ~200KB gzipped — and that includes SMILES parsing, 2D coordinate generation, SVG rendering, ECFP4 fingerprint similarity, and PDB parsing. The size difference isn’t magic; it’s the absence of Emscripten glue, Rust’s dead code elimination working cleanly across #[wasm_bindgen] exports, and wasm-opt running automatically on release builds.

Check your own binary size after building:

wasm-pack build --release
ls -lh pkg/*.wasm

If the .wasm is unexpectedly large, profile it with Twiggy to see what’s taking up space:

cargo install twiggy
twiggy top pkg/your_crate_bg.wasm

The Current Ecosystem State

Where things stand, mid-2025:

Practical Checklist

Before shipping a Rust WASM project:

1. Audit with cargo tree

   cargo tree --target wasm32-unknown-unknown | grep "-sys"

Any -sys crate is a potential blocker.

1. Remove wee_alloc — archived in August 2025, has a memory leak. The default dlmalloc is fine.

2. Handle getrandom explicitly — run cargo tree | grep getrandom to find the version, then add it explicitly to [dependencies] with the right feature flag, even if you don’t use it directly.

3. Replace system TLS — swap openssl/openssl-sys for rustls, or use reqwest with default-features = false, features = ["rustls-tls"].

4. Fix flate2 — use default-features = false, features = ["miniz"] to disable the libz-sys backend.

5. Build with --release — wasm-pack build --release runs wasm-opt automatically. Debug builds skip optimization and are typically 3–5x larger.

Closing Thought

The Rust-to-WASM path is genuinely good, and it’s improving. The C ABI for wasm32-unknown-unknown is being standardized (Rust blog, April 2025), wee_alloc‘s archival simplified the allocator story, and wasm-pack keeps getting better.

Most popular Rust crates predate WASM as a real target, and they picked up C dependencies along the way. The audit is tedious but a one-time fix — once you know which -sys crates to watch for and what replaces them, it doesn’t keep coming back.

I hit all four of these problems building chem-wasm-lens, a pure Rust + WASM molecular analysis library for the browser. The table above is what I found trying to go from a ~40MB Emscripten-compiled baseline down to ~200KB gzipped.

The Problem We Were Actually Solving

Our company, a platform for creators, needed a payment system that would work seamlessly worldwide, without relying on legacy banking systems. We wanted to enable creators to sell digital goods and receive payment in their local currency, without the hassle of foreign exchange fees or delayed transactions. We knew that the key to making this work lay in leveraging cryptocurrency, which lets us bypass traditional payment rails.

What We Tried First (And Why It Failed)

In the beginning, we opted to use a platform store like Stripe, which we thought would simplify our lives and let us focus on other aspects of the business. It took us about 2 weeks to set up and integrate, but the tradeoff quickly became apparent. Foreign exchange fees ate into our margins, and the latency between payment receipt and transfer to the creator was around 3-4 days. Not to mention the fact that Stripe restricted us from operating in certain countries, due to their own anti-money laundering policies. Our solution was far from ideal.

The Architecture Decision

After months of research and prototyping, we decided to automate order fulfillment for crypto payments from scratch. We chose to use the MetaMask API for browser-based wallets and the Chainlink Keepers for off-chain order fulfillment. This new architecture allowed us to take full control over the payment flow, which not only eliminated foreign exchange fees but also got payments to creators in under 24 hours. We achieved this by using smart contracts on the Ethereum blockchain to hold the funds until the creator’s order had been fulfilled, and then releasing them. We wrote our own custom API to handle these smart contracts and integrate them with our application.

What The Numbers Said After

By going fully custom, we were able to reduce our payment processing costs by 95% and cut down the average transaction latency to under 25 minutes. Queries on our database for order fulfillment only took 15 ms, a huge improvement over the 200 ms it used to take on the platform store. Our creators were able to receive payments in their local currency without any hassle, and the lack of foreign exchange fees meant higher earnings for them. We met our target of offering seamless global payments, without any geographical restrictions.

What I Would Do Differently

In hindsight, I would have built the custom payment system first, rather than going with the platform store. The time and effort we spent trying to work around its limitations could have been spent building something tailored to our needs. Additionally, I would have dug deeper into the smart contract logic and explored more complex use-cases. I would also have implemented some form of automated testing and deployment for the custom API to ensure its reliability and scalability. Looking back, the DIY payment solution was the right choice, but it required a good amount of trial and error to get it working smoothly.