Dan Levi Menchaca
I design data systems that are structured, scalable and built to recover.
From transactional databases to modern data pipelines — my focus is reliability, orchestration and long-term system stability.
A quick introduction
This short video shares how I think about data systems as critical infrastructure that supports decisions, operations and trust.
How I think about Data Systems
Data platforms are not isolated tools. They are ecosystems of pipelines, storage layers, transformations and business logic.
Most data problems don’t start in code — they start in architecture.Because of that, my thinking is guided by a few core principles:
Architecture before implementation — Understand ingestion patterns, dependencies and downstream consumers before building pipelines.
Orchestration over improvisation — Data workflows must be scheduled, monitored and observable.
Reliability over speed — Short-term fixes create long-term instability. I design systems that scale predictably.
Clarity over assumptions — Data engineering requires shared understanding across technical and business teams.
For me, a well-engineered data platform is one that behaves predictably, scales intentionally and recovers gracefully.
How I work
I approach data engineering with structure, modularity and long-term thinking.
Here’s what that looks like in practice:
I map the full data lifecycle — ingestion → transformation → storage → consumption.
I design modular pipelines — reusable components, clear responsibilities and version-controlled logic.
I prioritize observability — jobs are scheduled, monitored and measurable.
I optimize performance intentionally — indexing, execution plans and workload patterns are part of design, not afterthoughts.
I document architecture decisions — data dictionaries, ER diagrams, and integration logic.
I engineer for recovery — backups, redundancy and rollback strategies are integrated from the start.
Working with me means fewer surprises, cleaner data flows and infrastructure teams can trust.
Problems I’ve worked on
Below are examples of real data engineering challenges I’ve solved — not just fixing issues, but strengthening architecture.
a) Pipeline performance degradation in a growing transactional system.Context: A production system began showing slower data extraction and reporting as workload increased.
Approach: Analyzed execution plans, indexing strategies and workload distribution; redesigned ETL structure into modular, scheduled workflows and improved ingestion and transformation sequencing.
Outcome: Restored predictable performance, reduced blocking, and established a scalable pipeline structure for future growth.
b) Recurring deadlocks in high-concurrency data flows.Context: Data integrations between transactional systems and reporting layers generated recurring lock contention.
Approach: Analyzed transaction scope, isolation levels and execution patterns, then, optimized access ordering, reduced lock duration and adjusted pipeline scheduling.
Outcome: Significant reduction in deadlocks, improved transactional reliability and more stable data delivery to BI platforms.
The goal wasn’t speed or heroics — it was architectural clarity, stability and data reliability.
What I'm looking for
I’m looking for environments where data is treated as infrastructure — not just output.
More specifically, I’m interested in:
Teams building scalable data pipelines and cloud architectures
Organizations investing in Azure-based data platforms
Environments where orchestration, automation and reliability matter
Remote-first, collaborative teams
Long-term data platform evolution — not just short-term fixes
My goal is to help build data systems that support growth, resilience and forward-looking analytics.