About

I'm Bahri Gökcan, a backend tech lead in Antwerp, Belgium.

Across fifteen years, the stacks I've worked on have changed (from embedded real-time systems to distributed batch processing to today's ontology-driven data platforms), but the underlying discipline has stayed constant: correctness, observability, operational lifecycle, and designing for failure modes.

Today I lead the backend team for an operational intelligence platform used in mission-critical environments: the kind of system that pulls streaming, geospatial, and network data into a single ontology-driven layer, and supports a unified operational view, network analysis, and scenario simulation on top of it.

My team owns the backend end-to-end, from change-data-capture ingestion through the polyglot storage layer to the deployment and observability that keep it running.

The interesting trade-offs are at the seams: how one source of truth feeds the analytical layer, the knowledge graph, and search without the three diverging over time. The discipline is the one I learned in safety-regulated environments; the constraints now come from scale and concurrent users rather than from regulation.

That continuity goes back to 2011. While still finishing my computer engineering degree at Bilkent University in Ankara, I started on a fare-intelligence platform that tracked competitor pricing for an airline. I owned that codebase, in one form or another, for the next eleven years. The work taught me what it actually takes to keep a production system honest over a long horizon, against a hostile environment that changes underneath you.

Alongside the airline work, I spent several years at Turkey's defence-systems institute. Most of that work was mission planning software and embedded systems on real-time operating systems: code that had to run unchanged across different hardware and OS targets.

Around 2014 I also took on my first distributed-systems work there, designing the infrastructure and parallelization layer for a compute cluster running a workload built by another team. The cluster and the orchestration were mine; the workload itself wasn't. The cleanest engineering judgment I learned came from this environment: when failure isn't tolerable, you become careful about what you're really claiming.

Along the way I also co-founded two consumer startups (a price tracker and a mobile app for creating animated Instagram stories), both of which eventually closed. They taught me about shipping under resource constraints, and gave me a working understanding of how engineering and business decisions intersect when you own both sides.

I write here about the layer underneath architectural decisions. The technology that gets picked is usually well-documented. The constraint that drove the choice, the trade-off that was accepted, and the alternatives that almost made it rarely are. That's the layer I find most useful to read, so it's the one I try to write.

You can reach me on LinkedIn or by email at [email protected].