The conversation is a good reminder that even a simple user action, such as searching for a rental car at an airport, can hide a lot of engineering work. From the outside, the product looks straightforward: choose a location, dates and a car. Under the hood, the system may need to ask many different external systems for availability, prices, rental conditions, images and other details, then return something usable before the user loses patience.
One search can mean hundreds of moving parts
One of the key points from the episode is that a single car rental search does not equal a single API request. Depending on the location and type of search, one request can trigger tens or even hundreds of requests in the background. A direct airport search is usually simpler. A city-based or coordinate-based search can be much wider. And even one supplier integration may require several calls: authentication, available cars, pricing in batches, packages and other product options.
That makes speed a more interesting problem than simply optimizing one endpoint. Car Rental Gateway has to work with external systems that vary a lot in quality, speed and structure. Some APIs are modern and detailed. Others return limited data, use older formats, or require extra handling around missing fields. The platform has to wait long enough to return a useful result, but not so long that slow suppliers hold back the whole search. Kaspar described clear time limits, including partner-specific limits and hard stops, as part of making this manageable.
The data itself is another large part of the work. Suppliers do not describe cars, locations or conditions in one neat format. One company may return a car group as a model name, another as a code, and another through a different classification. Some suppliers may not provide full location details, coordinates or contact information. Rental conditions can arrive as long, poorly structured text, sometimes in imperfect English. Car Rental Gateway’s role is not just to pass data through. The platform also normalizes, enriches and translates it so the end result can be compared and understood.
The episode also gave a grounded view of integrations. In theory, integration work sounds like connecting API A to API B. In practice, it means dealing with inconsistent behavior, old systems, missing data, supplier-specific rules and changes that do not always arrive with perfect warning. Larger suppliers may change slowly. Smaller ones may break things more unexpectedly. Monitoring and fast reaction matter as much as the initial integration.
Architecture grows through real constraints
The architecture story is familiar to many SaaS teams. Car Rental Gateway started from a PHP monolith and has gradually moved toward microservices. The monolith still exists, though. Some parts are being moved out step by step, especially where performance or maintainability demands it. Other parts remain because they work and do not cause enough pain to justify rewriting them just for architectural neatness.
That balance was one of the more useful takeaways. The company now runs a large number of applications and services, but the goal is not microservices for their own sake. Service boundaries, documentation, standard APIs and shared ownership are what make the model workable. Kaspar also noted that some early service boundaries were over-engineered. That is probably the most honest lesson in the episode: architecture improves through use, mistakes and domain knowledge, not only through upfront design.
Caching and rate limiting came up as especially hard problems. Rental pricing can depend on many parameters, including location, dates, times, driver age, residence, sales channel and supplier-specific rules. Some prices may change several times per day. Some suppliers allow no caching, others allow a few minutes, others longer. That makes classic cache-hit thinking less useful. The work becomes more about understanding which parameters actually affect a supplier’s response and where a looser cache can be safe enough.
Observability is another practical layer. The platform uses logs, monitoring, alerts and internal tooling to detect issues, including problems in supplier responses. The team also has routines for technical support and incident handling, with teams rotating responsibility. That matters in a system where the customer-facing experience depends on many moving parts outside your direct control.
AI was discussed in a similarly practical way. Car Rental Gateway uses AI as a developer tool, but not as an autonomous replacement for engineering responsibility. Generated code still has to be reviewed, understood and owned by the developer.
The broader lesson from the episode is simple: a lot of engineering value sits in the unglamorous details. Normalizing supplier data, handling timeouts, tuning integrations, keeping legacy systems alive, choosing what not to rewrite, and making systems observable may not look exciting on an architecture diagram. But in real SaaS platforms, that is often where the hard work lives.
