index.json

[{"content":"If you’re paying per API call, every extra look costs you real dollars, but it goes way beyond that. Here is how you can calculate the actual cost of each look to optimize your traffic.\nUnderstanding Look to Book Ratio The Look to Book ratio measures how many search requests (looks) are needed to generate a single confirmed booking. The basic formula is:\n$$ \\text{Look to Book} = \\frac{\\text{Number of Searches}}{\\text{Number of Bookings}} $$\nFor example, if a travel platform submits 1,000 hotel searches and receives 50 bookings in return, the Look to Book ratio is:\n$$ \\frac{1,000}{50} = 20 $$\nThis means 20 \u0026ldquo;looks\u0026rdquo; are required to generate one booking.\nWhen 1 Search Becomes 150 Requests However, this simple ratio hides a significant portion of the actual cost incurred by suppliers and API providers. Here’s why:\n1. Search Requests Are Amplified Internally Most travel APIs allow a single search request to query hundreds of hotels at once. Therefore, the number of actual hotel lookups is much higher than the number of incoming search requests:\n$$ \\text{Effective Look to Book} = \\\\ \\frac{ \\text{Search Requests} \\times \\text{Avg. Hotels per Request} }{ \\text{Bookings} } $$\nIf each search request contains 50 hotels, and 1,000 search requests are made, that’s 50,000 hotel lookups—just for 50 bookings.\n2. Supplier Fan-Out Multiplies the Load Behind the scenes, many B2B travel platforms and wholesalers don\u0026rsquo;t own the hotel data—they aggregate it from multiple suppliers. Each hotel search may fan out to several supplier APIs. A more realistic metric of internal load becomes:\n$$ \\text{Adjusted Look to Book} = \\\\ \\frac{ \\text{Search} \\times \\text{Hotels} \\times \\text{Suppliers} }{ \\text{Bookings} } $$\nLet’s say each hotel query is routed to 3 suppliers:\n$$ \\frac{1,000 \\times 50 \\times 3}{50} = 3,000 $$\nThat’s 3,000 backend supplier requests per booking—a 150x increase from the original ratio.\nWhy This Matters Infrastructure Costs: Each additional supplier call increases server load, bandwidth usage, and cloud compute costs. Rate Limiting \u0026amp; Throttling: High look-to-book ratios can lead to suppliers throttling your access or charging higher fees. Opportunity Cost: Excessive looking can exhaust shared resources unfairly. Bad performing consumers can deplete your supplier\u0026rsquo;s quota therefore you cannot sell to better performing consumers. Rethinking the Metric Instead of just reporting a simple Look to Book ratio, travel companies should also track:\nFan-out factor (supplier load per search) Effective backend look volume Cost per successful booking, including compute and supplier overhead Conclusion\nThe Look to Book ratio has long been a trusted benchmark in travel commerce, but its true cost lies beneath the surface. By accounting for the amplification through hotel-level fan-out and supplier-level propagation, travel platforms can better manage infrastructure, negotiate smarter contracts, and design systems that reward efficient traffic—not just high volumes.\n","permalink":"/posts/hidden-cost-of-look-to-book/","summary":"\u003cp\u003eIf you’re paying per API call, every extra look costs you real dollars, but it goes way beyond that. Here is how you can calculate the actual cost of each look to optimize your traffic.\u003c/p\u003e\n\u003ch2 id=\"understanding-look-to-book-ratio\"\u003eUnderstanding Look to Book Ratio\u003c/h2\u003e\n\u003cp\u003eThe \u003cstrong\u003eLook to Book ratio\u003c/strong\u003e measures how many search requests (looks) are needed to generate a single confirmed booking. The basic formula is:\u003c/p\u003e\n\u003cp\u003e$$\n\\text{Look to Book} = \\frac{\\text{Number of Searches}}{\\text{Number of Bookings}}\n$$\u003c/p\u003e","title":"The Hidden Cost of Look to Book"},{"content":"In 2020, I stepped into the role of Chief Technology Officer at Yolcu360, a rapidly-growing car rental platform in Turkey. My main challenge: modernize our tech stack from a fragile monolith into something scalable, reliable, and easy to integrate with partners around the globe.\nHere’s how that transformation unfolded—and what I learned.\n🛠️ Breaking the Monolith: A Necessary Transition When I joined, Yolcu360’s core was a single, monolithic booking engine. While initially effective, this setup was now hampering our growth, slowing down deployments, and complicating integration.\nWe transitioned to a microservices architecture, primarily using:\nGo for critical services, chosen for performance and reliability. Kubernetes for service orchestration and deployment automation. Result?\nA 20-fold increase in throughput and dramatic improvement in reliability.\n🌍 Implementing GIS Without the Mapping Pain Location accuracy is essential for car rental services. Instead of the typical and painful manual location-mapping process, we designed a GIS-based system that eliminated traditional mapping steps. It supported:\n14 languages seamlessly Real-time provider integration Accurate location matching across thousands of providers It cut onboarding time significantly and made the customer experience smoother and faster.\n🤖 Launching a GPT-4 Powered Chatbot with Tool Use and UI Rendering One of our most exciting projects was developing an AI-driven chatbot. Our chatbot was far beyond basic Q\u0026amp;A—it was operational, interactive, and powered by GPT-4, with tool use and UI rendering capabilities which was not offered by OpenAI at the time. We built both tool use protocol, api and domain specific markup for UI rendering.\nStreaming LLM chains for real-time, interactive conversations. Ability to dynamically render forms and UI elements right inside the chat. Could invoke APIs directly, such as fetching real-time availability or completing bookings. This didn\u0026rsquo;t just automate interactions—it enhanced them.\n📈 Monitoring and Observability: Elastic + Prometheus Observability became a crucial part of our strategy. We shifted to a robust monitoring infrastructure using:\nElastic Stack for logs and metrics visualization. Prometheus for real-time monitoring and alerts. This combination gave us unprecedented visibility into performance, usage patterns, and errors, enabling proactive issue handling and continuous optimization.\n🚧 Challenges and Learnings Reflecting back, here’s what stood out:\nTransitioning from a monolith demands careful planning. Gradual migrations, not big-bang rewrites, are key. Chatbots are powerful tools—if their capabilities align directly with real operational needs. Good observability doesn\u0026rsquo;t just help operations—it drives product decisions and customer success. This experience shaped much of my thinking for LodgingBase. The ability to scale, integrate efficiently, and provide meaningful interactions is foundational—not just for car rentals, but for travel distribution at large.\nFacing similar challenges or interested in these approaches? Let’s chat.\n","permalink":"/posts/yolcu-stack/","summary":"The journey from monolith to microservices, integrating GIS logic, and launching a GPT-4 powered chatbot.","title":"CTO Journal #2: Transforming a Car Rental Stack at Yolcu360"},{"content":"Yolcu360 is the largest online car rental platform in Turkey. At its inception, the system was a traditional Django monolith—typical for early-stage startups. When I stepped into the CTO role, we were facing performance bottlenecks and instability during traffic surges. For example an ad campaign with discounts in a popular tv show would degrade system performance and waste marketing budget.\nThis is not a unique story. Many startups build MVPs quickly, and those temporary decisions become permanent as the business scales. Over time, technical debt compounds, and the monolith becomes a liability. You often hear “just a refactor will fix it,” but in reality, few systems can sustain that illusion.\nMicroservices aren\u0026rsquo;t a silver bullet. They introduce complexity and require discipline. But if your product is growing and the pace of change matters, staying monolithic means you\u0026rsquo;re eventually paying a tax on every new feature.\nWhy Microservices Were Faster for Us Not every microservice outperforms its monolithic counterpart—but breaking free from monolithic constraints opens up new avenues for scaling. We chose Go over Python for our concurrency-heavy services. That change alone allowed us to efficiently parallelize supplier requests. Introducing a centralized caching layer further reduced latency for high-volume lookups.\nMore importantly, services became \u0026ldquo;first-class citizens\u0026rdquo; in our Kubernetes environment. We could deploy, scale, and recover services independently—critical when traffic spikes were unpredictable and needed instant elasticity.\nThe Result After completing the migration:\nThroughput increased 20x, enabling us to handle surges without degradation. Latency dropped significantly in key user flows, as shown in the chart. Integration time decreased, thanks to a new provider-mapping toolchain. Team velocity improved, as smaller, isolated services made onboarding and iteration faster. This wasn’t just a technical rewrite. It was a foundational shift that aligned our platform with the future of on-demand mobility infrastructure.\n","permalink":"/posts/car-rental/","summary":"\u003cp\u003e\u003cstrong\u003eYolcu360\u003c/strong\u003e is the largest online car rental platform in Turkey. At its inception, the system was a traditional Django monolith—typical for early-stage startups. When I stepped into the CTO role, we were facing performance bottlenecks and instability during traffic surges. For example an ad campaign with discounts in a popular tv show would degrade system performance and waste marketing budget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThis is not a unique story\u003c/strong\u003e. Many startups build MVPs quickly, and those temporary decisions become permanent as the business scales. Over time, technical debt compounds, and the monolith becomes a liability. You often hear “just a refactor will fix it,” but in reality, few systems can sustain that illusion.\u003c/p\u003e","title":"Why We Moved to Microservices at Yolcu360"},{"content":"In 2017, I joined Metglobal, a major travel tech company with $350M+ in revenue, as Chief Technology Officer. My mission was clear: rebuild the core search and distribution engine to meet modern performance demands.\nWe were facing a bottleneck — not just in raw throughput, but in flexibility. Every change took too long to propagate, and scaling wasn’t linear. Here\u0026rsquo;s what we did — and what I learned.\n🚀 Building a High-Performance Travel Search Engine We rebuilt the search platform with:\nGo as the service language Bigtable as our low-latency storage layer GRPC for fast inter-service communication The result?\nWe hit 300,000 responses per minute, all under 300ms, using fewer than 20 VMs.\nThis brought a 90% drop in server costs and almost linear scaling.\nIt was the most performant backend I’d ever deployed.\n🧠 The Hard Parts (and What I\u0026rsquo;d Change) 1. Bigtable is brilliant — but brutal without planning Bigtable offered the speed we needed, but schema design was critical. When patterns shifted, re-architecting keys was painful.\nIf I were to do it again, I\u0026rsquo;d:\nAdd a caching layer earlier (even with low latency storage) Abstract more query logic from table structure 2. Auto-SDK Generation Pays Off We built an OAPI-based system that generated SDKs for different teams. It improved adoption and consistency across products.\nToday, I’d go further:\nUse Buf Connect or OpenAPI + Typescript SDKs directly Treat internal APIs like products — with versioning, docs, and test harnesses 3. Rule Engines Must Be Fast and Flexible We developed a product-level rule engine that adjusted prices and filters by hotel, room type, currency, provider, etc. It was powerful — but tuning it took deep domain alignment.\nNow, I’d build this with:\nCode-defined rules + low-code overrides Integrated analytics to see the impact of each rule 📊 Impact Beyond Tech The real win wasn’t just throughput.\nIt was how these decisions affected margin, market speed, and partner confidence.\nFast systems reduce retries, lower infrastructure bills, and increase the odds of conversion. In B2B travel, that matters more than ever.\n🧭 What This Taught Me as a CTO Performance alone isn’t enough. Performance that aligns with business strategy is. Developer experience is key to scalability — SDKs, APIs, and documentation aren’t luxuries. Building for throughput forces you to simplify smartly — and abstract wisely. This project ultimately played a big role in the company’s acquisition by GoGlobal.\nToday, those same principles shape the foundation of LodgingBase — the travel distribution platform I’m now building from scratch.\nIf you\u0026rsquo;re scaling a B2B system — in travel or otherwise — let’s connect. I’ve made all the mistakes already.\n","permalink":"/posts/metglobal/","summary":"How we built a travel search engine that served 450,000 requests per minute under 300ms, and what I’d do differently today.","title":"Serving 450,000 requests per minute in HotelsPro"}]