Last updated: Aug 2026

$ ./cat engineering-thinking.md

Engineering Thinking

I approach engineering problems by reducing them to constraints, choosing the right abstractions, understanding failure modes, and measuring the trade-offs.

Problem
Constraints
Model
Data Structures
Architecture
Failure Modes
Trade-offs
Measurement
Iteration

02 — Algorithms → Systems

How abstractions become infrastructure

GRAPH THINKING
• Service dependencies• Topology• Blast-radius analysis
EVIDENCEAPPLIED
ZeroDrift
TREE / AST
• Terraform structure• Dependency traversal• Static analysis
EVIDENCEAPPLIED
ZeroDrift
QUEUES
• Async processing• Backpressure• Failure isolation
EVIDENCEAPPLIED
RabbitMQ / Pub/Sub
HASHING / CACHE
• Deduplication• Caching• Load reduction
EVIDENCEAPPLIED
Redis

03 — System Design

Design Exercises & Analysis

Event Processing System

DESIGN EXERCISE

How I would reason about an event-driven system, drawing from Pub/Sub (ZeroDrift) and RabbitMQ (Cloud-Native) implementations.

REASONING AREAS
Event ingestion & stream semanticsQueueing & asynchronous workersBackpressure & overload handlingRetries & dead-letter handlingIdempotency & state mutationFailure isolationDistributed observability

Distributed Rate Limiter

DESIGN EXERCISE

A pure systems design exercise exposing algorithms, distributed state, and concurrency.

REASONING AREAS
Algorithm selection (Token Bucket vs Sliding Window)State management (Local memory vs Distributed Redis cache)Consistency models & race conditionsFailure behavior (Fail open vs fail closed)Horizontal scaling & traffic spikes

Job Scheduler / Work Queue

DESIGN EXERCISE

Connecting Priority Queues and scheduling algorithms to real infrastructure constraints.

REASONING AREAS
Priority queues & execution fairnessWorker pools & concurrency limitsRetry logic with exponential backoffBackpressure & queue depth monitoringDead-letter queues (DLQ) for unprocessable jobs

Observability Pipeline

ENGINEERING ANALYSIS

Conceptual analysis of telemetry ingestion and aggregation, aligned with SRE identity and Prometheus/Grafana usage.

REASONING AREAS
Telemetry ingestion & bufferingStorage & aggregation semanticsQuerying latency vs storage costCardinality limits & dimension explosionData retention & sampling strategiesAlerting failure modes

04 — Distributed

Operational Reality

RabbitMQ APPLIED
Asynchronous communication Failure isolation
Redis APPLIED
Distributed caching Database load reduction Session state
EKS / Microservices APPLIED
Distributed failure modes Service boundaries Network policies
Prometheus / Jaeger APPLIED
Distributed observability Telemetry aggregation Tracing

05 — Trade-offs

How I Choose

RabbitMQ vs Kafka

Documented Decision

RabbitMQ was utilized for service-to-service messaging and explicit failure isolation within the Cloud-Native Retail Platform.

Engineering Analysis

Kafka is favored when requirements shift toward higher throughput, strict event ordering, long-term event retention, and stream replay semantics.

Human approval vs Unrestricted automation

Documented Decision

The ZeroDrift architecture mandates explicit human approval before autonomous infrastructure changes proceed through the GitOps path.

Engineering Analysis

More autonomy equates to more operational authority, which exponentially increases the potential blast radius. The human approval boundary enforces the principle: Autonomy without unrestricted authority.

AST pre-analysis vs Direct execution

Documented Decision

ZeroDrift utilizes AST-based Terraform analysis to determine risk profiles prior to execution.

Engineering Analysis

While direct automation reduces deployment latency, pre-execution structural analysis enhances safety, bounds the blast radius, and improves explainability. It trades deployment speed for operational predictability.

Redis caching vs Direct database reads

Documented Decision

Redis was introduced to cache frequently accessed product data, actively reducing pressure on the PostgreSQL primary.

Engineering Analysis

Caching reduces read latency and database load, but fundamentally trades consistency for performance. It introduces operational complexity around cache invalidation, stale data windows, and memory capacity limits.

06 — AI Infrastructure

What should infrastructure be allowed to reason about?

Autonomy equates to operational authority, which exponentially increases the potential blast radius. The human approval boundary enforces safety.

Context → Model → Tools → Decision↓Human Approval Boundary↓Execution → Evaluation

07 — Failure Thinking

What breaks first?

Dependency failure→Queue backlog→Timeout→Retry storm→Cascading failure
Read Incident Reports & Post-Mortems

08 — Complexity Matters

Complexity is not only about Big-O. In infrastructure systems, the practical cost also includes memory, latency, concurrency, network calls, API limits, token usage, and operational complexity.

O(n)
Linear scans, log processing, dependency traversal
O(log n)
Search, indexing, tree operations
O(n log n)
Sorting, large-scale batch transformations
O(n²)
Pairwise comparisons, dependency explosion, poorly bounded analysis

"Good engineering is not choosing the most sophisticated solution. It is choosing the simplest system that satisfies the constraints—and understanding exactly how it fails."

01. Understand the problem02. Write the constraints03. Define failure modes04. Choose the data model05. Choose the algorithm06. Design the architecture07. Measure08. Break it intentionally09. Observe the failure10. Iterate
Next

See those ideas applied

Engineering Systems