Building a Production eBPF Observability & Security Stack for Kubernetes in 2026

Understanding what’s happening inside a production Kubernetes cluster running thousands of containers remains one of the hardest operational challenges. Attaching sidecar proxies increases resource overhead, and embedding SDKs requires application code changes. eBPF (extended Berkeley Packet Filter) solves this problem at the kernel level. According to the 2026 CNCF Observability Technical Advisory Group (TAG) survey, 67% of teams running Kubernetes at scale have already adopted at least one eBPF-based observability tool in production.

This guide covers everything from the latest announcements at KubeCon EU 2026 to building a complete production observability and security stack with Cilium, Tetragon, Grafana Beyla, and the newly launched OpenTelemetry eBPF Instrumentation (OBI).

Why eBPF Became the Standard for Kubernetes Observability

Let’s start by comparing traditional observability approaches with the eBPF-based approach. The key insight is: “Collect telemetry directly from the kernel without any code changes.”

An eBPF program runs just once per node and collects telemetry for every Pod on that node. Even with 100 Pods, you need a single DaemonSet instead of 100 sidecars. This is why eBPF has an overwhelming advantage at scale.

2026 Production eBPF Stack Architecture

The most battle-tested eBPF production stack in 2026 consists of four core components, each with clearly separated responsibilities. All are CNCF projects or part of the CNCF ecosystem.

As shown in the diagram above, Cilium/Hubble handles the network layer, Tetragon handles the security layer, OBI/Beyla handles application tracing, and all telemetry is delivered to backends (Grafana, Prometheus, Tempo) through the OpenTelemetry Collector.

Kernel Version Requirements

Choosing the right kernel version is critical for deploying the eBPF stack in production. The minimum requirement is 5.10 LTS, and the recommended version for 2026 production use is 6.1+.

Tip: Using kernel 6.1+ with CO-RE (Compile Once, Run Everywhere) support means you can deploy eBPF programs without recompiling on each node. For EKS, choose Amazon Linux 2023 or Bottlerocket AMI. For GKE, use Container-Optimized OS.

Step 1: Cilium + Hubble — Network Observability

Cilium is an eBPF-based CNI (Container Network Interface) that replaces traditional iptables with L3/L4/L7 network policies and observability capabilities. Hubble is the network observability layer on top of Cilium, providing service map visualization and flow logs.

Installing Cilium (Helm)

# Install Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --fail --remote-name-all 
  https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz

# Install Cilium + Hubble via Helm
helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.16.5 
  --namespace kube-system 
  --set hubble.enabled=true 
  --set hubble.relay.enabled=true 
  --set hubble.ui.enabled=true 
  --set hubble.metrics.enableOpenMetrics=true 
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_ip,destination_namespace,destination_workload,traffic_direction}" 
  --set prometheus.enabled=true 
  --set operator.prometheus.enabled=true 
  --set kubeProxyReplacement=true

Verifying Hubble Network Flow Observation

# Check Cilium status
cilium status --wait

# Observe real-time flows with Hubble CLI
hubble observe --namespace default --follow

# Filter traffic between specific services
hubble observe 
  --from-namespace production 
  --to-namespace production 
  --to-label app=api-gateway 
  --protocol TCP 
  --verdict FORWARDED

# Filter by HTTP response code (L7 observation)
hubble observe --http-status 500 --namespace production

# Port-forward to Hubble UI for service map visualization
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

Once you access the Hubble UI, you can see real-time service maps of all inter-service traffic in the cluster. L7 protocol-level (HTTP, gRPC, Kafka) request/response metrics are also collected automatically.

Cilium Network Policy Example

# cilium-network-policy.yaml
# L7 HTTP policy from API Gateway to backend services
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-gateway-to-backend
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: api-gateway
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/.*"
              - method: "POST"
                path: "/api/v1/.*"
                headers:
                  - 'Content-Type: application/json'

Step 2: Tetragon — Runtime Security Observability

Tetragon is a Cilium sub-project and CNCF project that uses eBPF to observe runtime security events directly from the kernel and enforce policies. It monitors process execution, file access, network connections, and system calls in real time, with the ability to block threats at the kernel level instantly.

Installing Tetragon

# Install Tetragon via Helm
helm repo add cilium https://helm.cilium.io
helm repo update

helm install tetragon cilium/tetragon 
  --namespace kube-system 
  --set tetragon.grpc.address="localhost:54321" 
  --set tetragon.exportFilename="/var/run/cilium/tetragon/tetragon.log" 
  --set tetragon.enableProcessCred=true 
  --set tetragon.enableProcessNs=true

# Install tetra CLI (for event observation)
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --remote-name-all 
  https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz
sudo tar -C /usr/local/bin -xzvf tetra-${GOOS}-${GOARCH}.tar.gz
rm tetra-${GOOS}-${GOARCH}.tar.gz

TracingPolicy: Detecting Sensitive File Access

# tracing-policy-sensitive-files.yaml
# Detect and block access to sensitive files like /etc/shadow, /etc/passwd
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-access
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/etc/kubernetes/pki"
                - "/var/run/secrets/kubernetes.io"
          matchActions:
            - action: Sigkill   # Immediately terminate the process
            - action: Post      # Send event log

TracingPolicy: Detecting Privilege Escalation

# tracing-policy-privilege-escalation.yaml
# Detect privilege escalation attempts inside containers
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: privilege-escalation-detect
spec:
  kprobes:
    - call: "__x64_sys_setuid"
      syscall: true
      args:
        - index: 0
          type: int
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "0"   # Attempt to change to UID 0 (root)
          matchNamespaces:
            - namespace: Pid    # Container PID namespace
              operator: NotIn
              values:
                - "host_init_pid"  # Not host init process
          matchActions:
            - action: Sigkill
            - action: Post

Real-time Security Event Observation

# Observe real-time process execution events
kubectl exec -n kube-system ds/tetragon -c tetragon -- 
  tetra getevents -o compact

# Example output:
# process default/nginx-7d8b49557c-x2k9p /bin/sh -c "cat /etc/shadow"
# exit    default/nginx-7d8b49557c-x2k9p /bin/sh -c "cat /etc/shadow" SIGKILL
# -> /etc/shadow access attempt blocked immediately

# Detailed event output in JSON format
kubectl exec -n kube-system ds/tetragon -c tetragon -- 
  tetra getevents -o json | jq '.process_exec | {pod: .process.pod.name, binary: .process.binary, args: .process.arguments}'

# Filter events by specific namespace
kubectl exec -n kube-system ds/tetragon -c tetragon -- 
  tetra getevents -o compact --namespace production

Step 3: OBI / Grafana Beyla — Zero-Code APM Tracing

OpenTelemetry eBPF Instrumentation (OBI) is the zero-code observability solution that Splunk announced in beta at KubeCon EU 2026. Originally developed by Grafana Labs as Beyla, it was donated to the OpenTelemetry project and is now co-developed by Grafana Labs, Splunk, Coralogix, Odigos, and other vendors.

OBI monitors network traffic using eBPF to automatically generate distributed traces and RED metrics (Rate, Errors, Duration). It supports all major languages without code modifications, including Go, Java, Python, Node.js, .NET, Ruby, C/C++, and Rust.

Deploying Beyla DaemonSet

# beyla-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: beyla
  namespace: observability
  labels:
    app: beyla
spec:
  selector:
    matchLabels:
      app: beyla
  template:
    metadata:
      labels:
        app: beyla
    spec:
      serviceAccountName: beyla
      hostPID: true           # eBPF needs access to host processes
      hostNetwork: true       # Required for network traffic capture
      containers:
        - name: beyla
          image: grafana/beyla:1.9
          securityContext:
            privileged: true    # Required for loading eBPF programs
          env:
            - name: BEYLA_OPEN_PORT
              value: "80,443,3000,8080,8443,9090"  # Ports to observe
            - name: BEYLA_SERVICE_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: "http://otel-collector.observability:4318"
            - name: OTEL_EXPORTER_OTLP_PROTOCOL
              value: "http/protobuf"
            - name: BEYLA_KUBE_METADATA_ENABLE
              value: "true"     # Auto-tag with Pod/Service metadata
            - name: BEYLA_TRACE_PRINTER
              value: "disabled"  # Disable stdout output in production
          volumeMounts:
            - name: sys-kernel
              mountPath: /sys/kernel
              readOnly: true
      volumes:
        - name: sys-kernel
          hostPath:
            path: /sys/kernel

Advanced Beyla Configuration (ConfigMap)

# beyla-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: beyla-config
  namespace: observability
data:
  beyla-config.yml: |
    # Network-based auto-discovery
    discovery:
      services:
        - k8s_namespace: production
          k8s_deployment_name: ".*"
        - k8s_namespace: staging
          k8s_deployment_name: ".*"

    # RED metrics configuration
    routes:
      unmatched: heuristic    # Automatic URL pattern grouping
      patterns:
        - /api/v1/users/{id}
        - /api/v1/courses/{id}
        - /api/v1/courses/{id}/lessons/{lessonId}

    # Trace sampling (production cost savings)
    sampler:
      type: parentbased_traceidratio
      ratio: 0.1              # 10% sampling

    # Metrics export
    otel_metrics_export:
      endpoint: http://otel-collector.observability:4318
      protocol: http/protobuf
      interval: 15s

    # Traces export
    otel_traces_export:
      endpoint: http://otel-collector.observability:4318
      protocol: http/protobuf

Step 4: OpenTelemetry Collector — Unified Telemetry Hub

All telemetry collected from eBPF components is delivered to final backends through the OpenTelemetry Collector. The Collector handles data filtering, transformation, and routing, so you don’t need to change your collection infrastructure when swapping backends.

# otel-collector-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
  namespace: observability
data:
  config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318

      # Hubble metrics collection (Prometheus scrape)
      prometheus:
        config:
          scrape_configs:
            - job_name: hubble
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  regex: cilium
                  action: keep

    processors:
      batch:
        timeout: 10s
        send_batch_size: 1024
      memory_limiter:
        check_interval: 5s
        limit_mib: 512
        spike_limit_mib: 128
      k8sattributes:
        extract:
          metadata:
            - k8s.namespace.name
            - k8s.deployment.name
            - k8s.pod.name
            - k8s.node.name
        pod_association:
          - sources:
              - from: resource_attribute
                name: k8s.pod.ip

    exporters:
      # Prometheus (metrics)
      prometheusremotewrite:
        endpoint: "http://mimir.observability:9009/api/v1/push"
        tls:
          insecure: true
      # Tempo (traces)
      otlp/tempo:
        endpoint: "tempo.observability:4317"
        tls:
          insecure: true
      # Loki (logs)
      loki:
        endpoint: "http://loki.observability:3100/loki/api/v1/push"

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, k8sattributes, batch]
          exporters: [otlp/tempo]
        metrics:
          receivers: [otlp, prometheus]
          processors: [memory_limiter, k8sattributes, batch]
          exporters: [prometheusremotewrite]
        logs:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [loki]

Troubleshooting: Common Issues and Solutions

Issue 1: eBPF Program Loading Failure

The most common issue is eBPF program loading failure due to kernel version or security settings.

# Symptom: Beyla/Tetragon Pod in CrashLoopBackOff
# Diagnose the cause
kubectl logs -n kube-system ds/tetragon -c tetragon | grep -i "bpf|error|failed"

# Check kernel BTF (BPF Type Format) support
ls /sys/kernel/btf/vmlinux
# If file doesn't exist -> BTF not supported -> Kernel upgrade needed

# Check eBPF capabilities
bpftool feature probe kernel | grep -E "map_type|prog_type|attach_type"

# Fix: Upgrade node kernel (EKS example)
# Change managed node group AMI to Amazon Linux 2023
aws eks update-nodegroup-config 
  --cluster-name my-cluster 
  --nodegroup-name my-nodegroup 
  --launch-template name=my-template,version=2   # Use AL2023 AMI

Issue 2: Hubble Metrics Not Appearing in Prometheus

# Check Hubble metrics activation status
cilium config view | grep hubble

# Verify Hubble relay is healthy
cilium hubble port-forward &
hubble status

# Check Prometheus ServiceMonitor
kubectl get servicemonitor -n monitoring -l app=cilium

# Manually test metrics endpoint
kubectl exec -n kube-system ds/cilium -- 
  curl -s http://localhost:9965/metrics | head -20

# Fix: Explicitly enable Prometheus integration in Helm values
helm upgrade cilium cilium/cilium -n kube-system 
  --set hubble.metrics.enableOpenMetrics=true 
  --set prometheus.enabled=true 
  --set prometheus.serviceMonitor.enabled=true

Issue 3: Beyla Not Capturing Traffic for Specific Services

# Check Beyla discovery logs
kubectl logs -n observability ds/beyla | grep -i "discover|instrument"

# Problem: TLS traffic cannot be decrypted by default
# Fix: Enable uprobe for SSL libraries (Go/Node.js, etc.)
# Add to beyla-config.yml:
#   ssl:
#     enabled: true

# Problem: Service using non-standard ports
# Fix: Add the ports to BEYLA_OPEN_PORT environment variable
kubectl set env ds/beyla -n observability 
  BEYLA_OPEN_PORT="80,443,3000,5432,6379,8080,8443,9090,27017"

Conclusion: eBPF Stack Adoption Roadmap

The eBPF-based observability and security stack is no longer experimental technology in 2026. With Splunk officially announcing the OBI beta at KubeCon EU 2026 and Grafana Beyla being donated to the OpenTelemetry project, vendor-neutral standardization is advancing rapidly.

Here’s the recommended roadmap for production adoption:

1. Week 1-2: Verify and upgrade kernel version (6.1+). Install Cilium + Hubble on staging cluster. Migrate from existing CNI (Calico/Flannel).
2. Week 3-4: Deploy Tetragon and apply basic TracingPolicies (sensitive file access, privilege escalation detection). Benchmark performance against Falco.
3. Week 5-6: Deploy Beyla/OBI DaemonSet. Run in parallel with existing SDK-based instrumentation to verify data consistency. Adjust trace sampling ratio.
4. Week 7-8: Configure OTel Collector pipeline. Build Grafana dashboards. Set up alerting rules. Gradually roll out to production.

Future Outlook: In the second half of 2026, AI-driven threat detection applying ML to Hubble network flow data is planned. Additionally, the new tetragon-python SDK will allow writing eBPF security policies in Python that transpile to bytecode. eBPF is breaking down the boundaries between observability and security, evolving into a unified kernel-level observation platform.

Discord open-sourced Osprey, a safety rules engine processing 400 million daily actions and 2.3 million rules per second. Osprey uses a polyglot architecture: a Rust coordinator manages traffic, while stateless Python workers execute logic using a Python-based domain-specific language called SML. This design allows trust and safety teams to deploy real-time threat mitigations at high scale.

By Patrick Farry

This weekend I built a small tool to solve a very real (and annoying) problem…

I’ve been working with 4 monitors for a while now. My setup includes an ultrawide monitor as primary when I work, but, when I want play videogames I preffer use a 24″ monitor (when isn’t a simrace game), so, here are two cases were I need change my screens layout.

Every time I move between those setups, I have to manually rearrange monitors in Windows.

Doing that repeatedly? Not fun 😅, some times I do that 3 times peer day 🫠.

🤔 Looking for a solution

I tried to find an existing tool to automate monitor layouts, but nothing quite matched what I needed.

So I decided to build a simple CLI:

👉 wsm — Windows Screen Manager

A lightweight tool to save and restore monitor configurations as profiles.

⚡ What it does

The idea is simple:

• Save your current monitor layout
• Store it as a profile (YAML or JSON)
• Restore it instantly with a command

wsm save work -- save current layout
wsm load game -- load saved layout

If you frequently change your screen layout, this can save you a lot of time.

wsm list
Saved profiles in ~/.wsm-profiles:
  game — 4 monitor(s)
    Display 1: GBT340A                       3440x1440 @ 60Hz  pos (-1515, -1440)  primary: false
    Display 2: BNQ78E7                       1920x1080 @ 60Hz  pos (    0,     0)  primary: true
    Display 3: BNQ78E7                       1920x1080 @ 60Hz  pos (-1928,     0)  primary: false
    Display 5: ACI1643                       1080x1920 @ 60Hz  pos ( 1925,  -916)  primary: false
  work — 4 monitor(s)
    Display 1: GBT340A                       3440x1440 @ 60Hz  pos (    0,     0)  primary: true
    Display 2: BNQ78E7                       1080x1920 @ 60Hz  pos ( 3440,  -562)  primary: false
    Display 3: BNQ78E7                       1920x1080 @ 60Hz  pos (-1920,   350)  primary: false
    Display 5: ACI1643                       1080x1920 @ 60Hz  pos ( 4520,  -552)  primary: false

📦 How it works

Under the hood, the CLI:

• Reads all active monitors
• Captures:
• resolution
• refresh rate
• position in virtual desktop
• primary display
• orientation
• Stores everything in ~/.wsm-profiles

Example YAML:

profiles:
  office:
    monitors:
      - device_name: '\.DISPLAY1'
        friendly_name: 'Display 1: GS34WQCA'
        position_x: 0
        position_y: 0
        width: 3440
        height: 1440
        refresh_rate: 144
        bits_per_pel: 32
        orientation: 0
        is_primary: true
      - device_name: '\.DISPLAY2'
        friendly_name: 'Display 2: P2419H'
        position_x: 3440
        position_y: 180
        width: 1920
        height: 1080
        refresh_rate: 60
        bits_per_pel: 32
        orientation: 0
        is_primary: false

🧠 Atomic configuration changes

One important detail: applying layouts is done atomically.

Instead of changing monitors one by one (which can cause flickering or broken states), the tool:

• stages all changes using Windows APIs
• commits them in a single operation

This avoids intermediate invalid configurations.

Also:

• The primary display is always staged first
• Missing/disconnected monitors are handled gracefully

🧪 Built with AI

I built this using Claude, and had a working version in under an hour.

That said, it wasn’t just “generate and done”:

• There were bugs
• Edge cases around Windows APIs
• Iterations to get things stable

The AI helped a lot, but I still had to guide it and understand what was going on.

📈 Iterating on the idea

The first version was pretty basic:

• JSON files
• One file per configuration

Then I improved it:

• YAML as default (more readable)
• Profiles instead of separate files
• Still supports JSON if needed

🎛️ Stream Deck integration

Running commands is fine… but I wanted something faster.

So I built a plugin for the Elgato Stream Deck, this can run anny command on powershell or cmd.

Now I can switch my entire setup with a single button press.

🧠 A reminder about AI

I’ve been in software development for about 10 years.

Back then, the advice was:

“It’s fine to copy from Stack Overflow… but understand what you’re copying.”

That still applies today.

AI is powerful, but:

• It makes mistakes
• It hallucinates
• It doesn’t replace understanding

If something breaks, you still need to know how to fix it.

🚀 Try it out

If you’re on Windows and frequently change your monitor layout, this might be useful:

👉 https://github.com/OsirisFrik/windows-screen-manager

The layering problem

Applications often have many layers, such as repositories and ORMs, due to patterns like MVVM, MVC, and the Hexagonal architecture. My main argument is that these architectural decisions, while intended for general use, often feel rigid or contextless, especially for microservices or even monorepos. The art of architecture is about composing components into systems, but this process relies heavily on context and appreciation. Patterns exist as recipes for recurring problems, but when applied without context, they can feel forced and less relevant. Examples from books rarely match your real problem, and frameworks can lock you into abstractions that don’t match your needs.

Here’s my thought: let problems find you first. If they don’t, it’s either because they don’t belong or you don’t recognize them. Reading about them isn’t enough. It’s better to try building with these patterns elsewhere—not at work—unless guided by someone more experienced. Sometimes practice is best, or even necessary, when speed matters. Frameworks exist because they embed valid patterns for specific cases. Companies offer ready-made solutions like ORMs, ERPs, or Next.js; you may use them if patterns fit. Otherwise, question and resist the urge to apply patterns by default. Avoid Resume-Driven-Development traps.

Data-Driven Design

While there is literature about high-level architectural design and modules in “The Philosophy of Software Design” that I find interesting, the simplest and most effective driver I’ve found is data itself. My argument leads to a key idea: everything points toward a data-driven approach. Rather than starting with high-level abstractions, focus on your data. Shape your system by following your data and encoding it using clear, simple structures. This approach will usually simplify both design and tool selection, letting your data’s characteristics guide architecture and modeling choices to best suit your use case.

This is DDD at its core, and it also favors deep modules, as the referenced book says. Large modules should fade or be autogenerated. Focus on your domain and API simplicity, which depend on how well you encode data and its relationships. Here, DDD’s data aggregates help: when you need several objects to interact, think of them together as a unit, not just related items. This encourages simple design and cuts down race conditions, as changes to coupled parts remain atomic. Other concepts exist—better explained elsewhere—but everything comes down to business, data, or algorithm invariants. Find these invariants, then encode them. Use an automaton. If you could learn one thing in Computing Science, pick a DFA. It’s a first principle to help avoid over-engineering.

Automata and the Power of Explicit State

Finite Automata excel because they work with data and can process almost any computable input. Bugs often stem from accepting too much or omitting needed data. Protocols frequently use this concept. Though RFCs and implementations differ, starting with a DFA is wise for such problems. It’s the simplest way to define data boundaries and is nearly linear in speed. If your issue is data-related, always think it through with automation first. This clarifies your approach and shows if another data structure is needed. Don’t jump into polished solutions when starting new work, if you can avoid it.

Many think you shouldn’t build from scratch, which makes sense given today’s abundance of libraries. But if data is core to your business, treat it as seriously as outsourcing. Don’t outsource your core. Even without an MBA, I believe in this, and many smarter people agree. Books like Amazon’s “Working Backwards” or Netflix’s “Engineering Culture” strike me as well-meaning novels. Company realities are messier: every company is a ball of controlled technical chaos to keep up with business scale. To fight this, prioritize your principles as a technical lead and let business leaders handle the rest. Simplify early and check complexity with each new code addition.

Object-Oriented Pitfalls and the Relational Model Trap

Object-oriented programming’s downside is its link to the relational model. While not always true, big enterprise problems usually stem from data modeling. Academics start from relational algebra, which differs from category theory. Smalltalk’s background is separate from relational algebra, but it’s misapplied to enterprise systems. Originally, code automated processes, not fixed algorithms—this is a flawed outlook. Treat data as a first-class citizen from the start, not an afterthought. While we write in terms of behavior and output, we shouldn’t shape code solely for data or processes. It’s tricky, but embracing this shift leads to simpler code.

Final recommendations

Below are good starting points for my ideas. I have plenty of reinforcement bias, but I don’t recommend that, or linking to anything that isn’t my interpretation, since people might see things differently. A discussion forum might be better for debate than a blog post. If you’re interested, it’s better to look in books or projects rather than hearing from someone who shares your thoughts—unless it’s just for fun and entertainment, as I do.

• Screaming Architecture
• Boundaries

Finally, I leave you with some extra advice, from my discussion about the subject with my today’s victim, as lately, ChatGPT or whatever other LLM kind of chat. It turns out that’s the best way to challenge my thoughts nowadays, and it’s worth it for summary or tl;dr sections if you are that kind of guy. But I put it at the end just bc of that. Although I am still looking for perfection on those ideas and principles, if you like, I’m aware that the world is complex enough and you always need to deal with physics one way or another, that means you eventually will face reality and need to talk with external systems and distributed networks, even though you only have a database and OS as a runtime. Because of that, on scale, you will need to think in other layers as well. But that’s the point, if you already have enough layers on top of your system. Why did you shoot yourself in the foot and put more inside your app?

The clean mental model (ChatGPT extracted)

Think in three layers:

1. Domain (DDD core)
   • Strong invariants
   • Impossible invalid states
   • Explicit transitions
   • “What is allowed?”
2. Application / workflow
   • Ordering of steps
   • Retries
   • Orchestration
   • “What happens next?”
3. Infrastructure
   • DBs
   • Queues
   • APIs

Most bugs happen when:

• Layer 2 logic leaks into layer 1
• Invariants are not enforced in layer 1

Trying to cross-post here since I always wanted to give back to this community what I had learned from it. Other than that, my Substack looks pretty lonely so far. Check this out in case you found this article interesting (it will be published next week). And this may help me with early feedback to include corrections and examples there.