1. SVC-01

   System & Data Architecture

   Designing systems where data flows cleanly across boundaries — from sources to services to analytics — with clear structure and well-defined ownership.

   Context

   Postgres migration (SQL Server → PostgreSQL) via pgloader, with Kafka-based reverse-sync through Debezium CDC for zero-downtime rollback safety.

   PostgreSQL Kafka Debezium
2. SVC-02

   Data Pipelines & Platforms

   Building ingestion, transformation, and storage layers that are reliable, observable, and cost-aware.

   Context

   Ingestion pipelines on Databricks — API-based and file-based (SDP) — with cost and resource-usage dashboards for platform observability.

   Databricks Python
3. SVC-03

   Backend & Service Development

   Backend services and APIs that integrate cleanly with data systems and scale with growing complexity.

   Context

   Custom Python consumers for Kafka streams, bridging CDC events to downstream systems with idempotent, at-least-once processing.

   Python Kafka FastAPI
4. SVC-04

   Integration & Extensibility

   Systems that take on new tools, data sources, and alternatives without major rewrites.

   Context

   Heterogeneous sources — relational databases, object stores, streaming platforms — unified into a single lakehouse query surface.

   PostgreSQL Databricks Docker
5. SVC-05

   Optimization & Reliability

   Performance, cost efficiency, and failure handling grounded in how systems behave under load and change.

   Context

   Dual-write rollback strategies via Kafka CDC to cut migration risk; custom dashboards for Databricks spend and resource utilization.

   Kafka Databricks Python

principles that govern how I design data systems

1. 01

   ADR-01

   Systems Before Solutions

   Structure before tooling. A schema, a contract, or a boundary drawn early is worth a hundred fixes later. I pick the tool only after the system's shape is visible — a Kafka topic chosen before the bounded context is a load-bearing decision made blind.

2. 02

   ADR-02

   Design for Extension, Not Correction

   Change should read like an addition, not a patch. If integrating the next source means rewriting the core, the core was never the core — it was a coincidence that happened to work.

3. 03

   ADR-03

   Leave Space at the Edges

   Boundaries are where systems stay adaptable. I push irreversible decisions inward and keep the perimeter reversible: schema, contracts, ownership. The edge is where the next unknown system will arrive.

4. 04

   ADR-04

   Complexity Must Be Earned

   I start with the boring pipeline and the obvious table. Complexity is justified by load, by cost, or by a failure I can name — never by resume appeal, and never before the simpler version has been measured.

5. 05

   ADR-05

   Data You Can Reason About

   Moved data is a liability; understood data is an asset. A pipeline is only done when it ends in a question someone can actually ask of it — and an answer they can trust.

Closing Rule

Build for the system you understand. Leave room for the one you will meet next.

1. DOM-01

   Data Systems

   5/5

   Designing how data moves, transforms, and settles across systems — from raw ingestion to analytics-ready outputs — with attention to structure, observability, and evolution.

   Pipelines, storage layers, batch and stream patterns, data modeling.

   PostgreSQLKafkaDebeziumDatabricksdbtAirflow
2. DOM-02

   Backend & Services

   4/5

   Building backend services that expose, consume, and coordinate data through well-defined interfaces, with a focus on correctness, scalability, and clean integration.

   APIs, service boundaries, background workers, internal tooling.

   PythonFastAPIGoRESTPostgreSQLevent-driven patterns
3. DOM-03

   Distributed & Infrastructure-Aware Systems

   3/5

   Working with systems that run across multiple components — understanding deployment constraints and operational trade-offs. Not infrastructure for its own sake, but enough context to design responsibly and avoid fragile systems.

   Enough context to design responsibly and avoid fragile systems.

   DockerLinuxCDC patternsinfrastructure as code
4. DOM-04

   Developer Tooling & Automation

   3/5

   Creating internal tools, scripts, and workflows that reduce friction, improve visibility, and make systems easier to operate and extend.

   A developer-first approach to system design and operability.

   PythonAirflowdbtdashboardspipeline monitoring
5. DOM-05

   Data Reasoning & Analysis

   4/5

   Reasoning about data correctness, quality, and behavior — validating assumptions, tracing issues, and ensuring outputs are trustworthy.

   Analytics is an outcome, not the primary goal.

   SQLcost analyticsdata quality validationdbt
6. DOM-06

   Agentic AI & Tool-Augmented Systems

   2/5

   Applying systems-thinking to AI agent architectures — orchestrating tools, skills, memory, and data flows through well-defined interfaces. Agentic systems are, at their core, integration and orchestration problems.

   Systems-level perspective on agent design — composition, tool discovery, and state/context flow across interactions.

   LangChainLLM APIsagent orchestrationtool-augmented reasoning

If you're working on systems that need to grow without losing clarity, I'd like to talk.

I design data platforms built to evolve under load — where system design, infrastructure, and long-term clarity meet. Currently looking for the next system worth signing my name to.

• GitHub ↗ — Experiments, infra tooling, and notes-in-progress
• LinkedIn ↗ — Brief history and current focus