You know that feeling. You’re building a system, and you need to make writes fast. So you cut corners. You skip validation, defer schema enforcement, dump raw data and promise yourself you’ll clean it up later. It feels great. The numbers look amazing on your dashboard. But somewhere in the back of your mind, a quiet dread is already forming. Because you know—deep down—that the bill is coming due.
Every fast write is an IOU to your future self, and the interest rate is brutal.
This isn’t a new idea. It’s a principle that shows up everywhere: in data platforms, API design, storage systems, even in how we write code. The faster you make the write path, the more work you push downstream. Schema-on-read is the classic example. You skip schema resolution at write time, and suddenly every reader has to figure out what the data means. The write is fast, but the read is a nightmare of parsing, guessing, and handling inconsistencies. You’ve optimized a metric while sabotaging the whole system.
Speed at write time is just an accounting trick that shifts the bill from the producer to the consumer.
I saw this firsthand in a data platform I consulted on. The team was proud of their sub-millisecond write latency. They’d built a pipeline that ingested raw JSON with zero transformations. Beautiful. But six months later, the analytics team was drowning. Every query required complex parsing, field extraction, and error handling. The write path was a dream. The read path was a nightmare. The total cost of the system—end-to-end work—was actually higher than if they’d spent a few extra milliseconds validating and structuring the data on write.
This is the trap. We measure what’s easy to measure: write latency, throughput, response times. We celebrate the quick win. But the deferred complexity doesn’t disappear. It just relocates. It hides in brittle pipelines, in buggy readers, in the endless debugging sessions that happen when someone tries to actually use the data. Optimizing for write speed without considering read cost is like building a highway that ends in a dirt road.
So what’s the solution? Stop optimizing for a single metric. Start measuring the total work: write time plus read time, plus the cognitive load of understanding the data, plus the cost of fixing the inevitable mess. Demand end-to-end accountability. If you’re going to make writes fast, make sure you’re not just passing the buck to the next person in the chain.
The next time you celebrate a fast write, remember: you’re just kicking the can down the road. And eventually, that road leads back to you.
FAQ
Q: Isn't it sometimes worth it to make writes fast if reads are rare or batch-processed?
A: Sure, if you control the entire pipeline and the read workload is negligible. But most systems have multiple readers, and the cost multiplies. The principle holds: you're still moving work, not eliminating it. Just be honest about the trade-off.
Q: What's the practical takeaway for someone designing a data platform today?
A: Measure end-to-end latency, not just write latency. Model the total work: write cost + read cost + maintenance cost. If you can't estimate the downstream cost, you're flying blind. Prefer schema-on-write for most use cases, or at least enforce a contract at write time.
Q: The contrarian take: isn't this just 'technical debt' with a new name?
A: Technical debt is a broader concept. This is a specific, measurable pattern: the conservation of work in a system. It's not debt—it's a physics law. You can't make work disappear; you can only move it. Acknowledging that is more useful than hand-waving about debt.