Blog

The guiding principle (the motto) Keep UTC for as long as possible. Change to a local timezone only when it is truly required. This principle was not theoretical. It emerged from a real incident — one that almost became a production bug, and only didn’t because of a fortunate configuration coincidence. Why time zones are dangerous in ETL Time-related issues are among the hardest problems in data engineering because: ...

Summary I was generating deterministic UUID v5 primary keys from business keys. It worked well—until subtle but serious collision risks appeared: Ambiguous concatenation (ab + cd vs a + bcd) Cross-table collisions (different tables, same business values → same UUID) This post presents a clean, modular solution using explicit separators and namespace scoping, and explores the harder problem of multi-source ingestion. ⚙️ Context & Problem In data platforms and ETL systems, business keys are often the only stable identifiers available (for example, composite natural keys). To ensure idempotency and simplify upserts and deduplication, a common pattern is: ...

Resumo: Indexes are one of the first performance tools every PostgreSQL user learns — and one of the easiest ways to accidentally slow a system down. This article explains how indexes actually work, why they are never free, how different index types behave in real workloads, and how fillfactor quietly determines whether your database ages gracefully or slowly collapses under write pressure. Indexes Feel Like Magic (At First) You run a query on a table with millions of rows. ...

Summary: ORMs make development faster, but mastering SQL and database internals turns good backend engineers into great ones. Here’s why understanding both levels — abstraction and reality — matters. ⚙️ Context & Problem Modern web frameworks — Django, FastAPI, Spring Boot, Laravel — all encourage the use of Object-Relational Mappers (ORMs). They make it easy to map objects to tables, run queries in a few lines of code, and forget about SQL altogether. ...

🧩 The Classic Problem: When a Service Doesn’t Respond Imagine the following flow in a service-oriented system: Client → the-api → the-upstream → Database 1️⃣ The client calls the-api/v1/test 2️⃣ the-api calls the-upstream 3️⃣ the-upstream writes data into its own database 4️⃣ It replies OK to the-api 5️⃣ the-api stores the result in its database and replies OK to the client Everything works fine — until step 4 (D) fails because of a network partition or timeout. Now, the-api doesn’t know if the upstream actually wrote the data or not. You can’t safely commit your local write — and you can’t confidently reply to the client. ...

Building a Production-Grade Unit of Work (UoW) System in Python with SQLAlchemy When you build complex applications with databases, services, and background jobs, you eventually run into the transaction problem: How do I guarantee all operations happen atomically? How do I handle nested scopes (reuse vs rollback)? How do I ensure events are only published once? How do I protect against duplicate commits when retries happen? The solution is a Unit of Work (UoW) system — a design pattern that wraps all your persistence operations in a clear, explicit transaction boundary. ...

Resumo: Como automatizei a reconciliação mensal de contribuições entre um ERP e um portal externo. Mostro padrões reutilizáveis: bounded concurrency, retry com backoff + jitter, tolerância monetária, bucketização por período+taxa e upsert idempotente de divergências — usando value objects (YearMonth, Money) e ports (interfaces). Sem expor integrações reais: o foco é a arquitetura e as ideias reutilizáveis. ⚙️ Contexto & Problema Em RH, após o processamento salarial (até dia 10 em PT), é enviado o mapa de contribuições do mês anterior para o portal oficial. Se ocorrerem alterações após o envio (ajustes, faltas, prémios, correções), é fácil esquecer o reenvio do mapa corrigido — gerando inconsistências com risco regulatório e retrabalho. ...

🔢 Problem Statement LeetCode 14 – Longest Common Prefix Given an array of strings, return the longest common prefix among them. If no common prefix exists, return an empty string (""). Example 1 Input: ["flower", "flow", "flight"] → Output: "fl" Example 2 Input: ["dog", "racecar", "car"] → Output: "" Constraints 1 ≤ strs.length ≤ 200 0 ≤ strs[i].length ≤ 200 strs[i] contains only lowercase English letters if non-empty. 👨‍💻 Solution Strategies We’ll explore and compare five distinct approaches, from brute force to divide & conquer: ...

From Spreadsheets to Scripts: My Journey Automating Accounting with Python My journey into process automation started at an accounting firm, where I quickly found myself buried in repetitive manual tasks and inefficient workflows. From processing invoices to reconciling spreadsheets, I could see how much time was being lost to work that could — and should — be automated. When I started working there, I spent the first few months organizing paperwork and doing basic data entry. I quickly realized two things: ...

🧩 Problem: Roman to Integer (LeetCode 13) Convert a string representing a Roman numeral into its integer value. Roman numerals are typically written from largest to smallest (left to right), except for six well-known subtractive cases: I before V or X → 4, 9 X before L or C → 40, 90 C before D or M → 400, 900 ✅ Clean Idiomatic Solution (One-Pass) class Solution: SYMBOLS = { 'I': 1, 'V': 5, 'X': 10, 'L': 50, 'C': 100, 'D': 500, 'M': 1000 } def romanToInt(self, s: str) -> int: total = 0 prev_value = 0 for c in s: value = self.SYMBOLS[c] total += value - 2 * prev_value if value > prev_value else value prev_value = value return total Single loop Detects subtractive patterns with value > prev_value Clean inline logic ✅ Runtime: 3 ms (faster than 79.17%) ✅ Memory: 17.6 MB (less than 90.19%) ...