--- title: "Microservices for a Travel Booking Platform: Worth It?" description: "An honest assessment of the benefits and costs of our microservices architecture after two years — what worked, what we would redraw, and advice for teams considering it." canonical: https://nowah.xyz/blog/microservices-travel-platform-worth-it lastModified: "2026-08-07T03:53:04.971Z" --- # Microservices for a Travel Booking Platform: Worth It? An honest assessment of the benefits and costs of our microservices architecture after two years — what worked, what we would redraw, and advice for teams considering it. We chose microservices two years ago. I'm not going to tell you it was the right decision and leave it at that. The honest answer is more nuanced. Some parts of the architecture have justified the complexity many times over. Other parts make me wonder if we would have been better off with a well-structured monolith. Here's what we gained, what we paid, and what I'd tell a team making the same decision today. ## Why we chose microservices ![Illustration for this section](https://pics.nowah.xyz/website-media/infrastructure-064-img-1.webp) The theoretical arguments for microservices are well-known: independent deployment, team autonomy, isolated failure domains, technology flexibility. I won't rehearse them all. Here's what actually mattered for us. **Independent deployment for the AI agent.** The AI agent is the most rapidly evolving part of our platform. Prompt changes, tool additions, model upgrades, and behavior adjustments happen multiple times per week. The [payment processing](/blog/launching-payment-processing-ai-handles-money) code changes maybe once a month. If both lived in the same deployment unit, every agent tweak would carry the risk of breaking payment processing. Separate deployment means agent changes ship independently, tested against their own test suite, with no possibility of introducing a regression in the payment path. **Isolated failure domains for workers.** Our background job system runs seven named queues: booking operations, notifications, document generation, analytics, and several others. Each queue is processed by dedicated workers. If the document generation worker has a memory leak and crashes, booking confirmations and notifications continue processing. The leak is isolated to one worker type. In a monolith, the same leak might crash the entire process. **Team boundaries.** Different engineers own different services. The engineer working on the booking flow doesn't need to understand the notification pipeline's internals, and vice versa. Service boundaries create ownership boundaries. Each service has a clear owner who understands its behavior, its failure modes, and its performance characteristics. ## The costs we pay The benefits are real. So are the costs. **Operational complexity.** Instead of one server process, we run multiple. Each needs monitoring, logging, health checks, and alerting. The [deployment pipeline](/blog/deployment-pipeline-commit-production) deploys each service independently, which means more pipeline configuration, more deployment steps, and more potential failure points. A monolith deploys once. Microservices deploy N times. **Distributed debugging.** When a booking fails, the failure might originate in the API server, the payment service, the booking worker, or the travel data integration. The request crosses service boundaries, and each boundary is a potential loss of context. We use correlation IDs to trace requests [across services](/blog/tracing-booking-across-services), but the debugging experience is still harder than stepping through a single process in a debugger. **Cross-service communication overhead.** Services communicate via HTTP with request-signature authentication for service-to-service calls. This adds latency (network round-trips instead of function calls), complexity (authentication, serialization, [error handling](/blog/error-handling-conversational-systems) for each call), and failure modes (network partitions, timeouts, service unavailability). A function call in a monolith takes microseconds and never fails due to network issues. **Data consistency challenges.** With a single database in a monolith, transactions are straightforward. With services that own their own data, a booking that involves creating a trip record, a payment record, and a notification record requires coordination across services. We handle this with idempotent operations and eventual consistency, but it's more complex than a single database transaction. ## What worked well ![Supporting diagram](https://pics.nowah.xyz/website-media/infrastructure-064-img-2.webp) The AI agent as an independent service was the clearest win. We deploy agent changes daily, sometimes multiple times a day. The deployment is fast, the blast radius is limited, and the iteration speed is exactly what we need for a rapidly evolving AI product. Worker isolation paid for itself during our [worst production incident](/blog/worst-production-incident). A runaway analytics query overwhelmed the database, but because the workers ran as separate processes, we could identify and stop the offending worker without bringing down the entire platform. Service boundaries forced clear API contracts between components. This clarity makes it easier to reason about the system, easier to test individual components, and easier to onboard new engineers. They learn one service at a time instead of trying to understand the entire system simultaneously. ## What we'd redraw If I were starting over with what I know now, I'd draw the service boundaries differently in two places. **The notification pipeline should have started as a library, not a service.** The notification system (email, [push notifications](/blog/launching-push-notifications-travelers-informed), in-app alerts) is a cross-cutting concern used by every other service. Making it a separate service means every notification requires a cross-service call with all the associated overhead and failure modes. A shared library that each service imports would be simpler and faster. The notification pipeline doesn't need independent scaling or deployment because it changes infrequently and its load is proportional to the other services' load. **The booking flow should be more tightly coupled.** The booking flow involves the API server (receiving the request), a booking worker (processing the booking), and the payment service (handling the charge). Three services coordinating a time-sensitive, money-moving transaction. The coordination adds latency and complexity. If I were redesigning, I'd keep the booking flow in a single service with the payment integration as a library dependency, not a service call. ## When a monolith is the right choice I'll say something that might be controversial in 2026: a monolith is the right choice for most teams starting out. Here's why. A monolith is faster to build. One deployment, one database, one process. No service-to-service communication to design. No distributed tracing to implement. No multi-service deployment pipeline to configure. You ship features faster. A monolith is easier to debug. One process, one debugger, one set of logs. When something breaks, you step through the code. No correlation IDs, no cross-service logs, no network layer to investigate. A monolith is easier to operate. One container, one health check, one scaling knob. The operational burden of running one process is a fraction of running five. The microservices advantages (independent deployment, isolated failures, team autonomy) don't matter until you have the scale and team size that makes them matter. For a team of 3-5 engineers, service boundaries are overhead. For a team of 20+, they're essential. ## The modular monolith middle ground There's a path between monolith and microservices that captures some benefits without the full cost: the modular monolith. A modular monolith is a single deployable process where the internal structure is organized into modules with clear boundaries. Each module has its own directory, its own interfaces, and its own data access patterns. Modules communicate through defined internal APIs, not direct database queries or shared state. The key is that the module boundaries look like service boundaries, but without the network call. Communication is a function call, not an HTTP request. Data consistency is a database transaction, not an eventual consistency protocol. Deployment is a single process, not a multi-service orchestration. When a module needs to become an independent service (because it needs independent scaling, different technology, or separate deployment), the boundary is already defined. The extraction is straightforward because the module was already communicating through a defined interface. We didn't start with a modular monolith. I wish we had. Several of our service boundaries were drawn too early, before we understood the communication patterns and coupling between components. Starting modular and extracting services as needed would have given us better boundaries with less upfront cost. ## The decision framework If you're deciding between monolith and microservices, here are the questions that actually matter. **How many engineers will work on this concurrently?** Under 5, a monolith. Under 15, a modular monolith. Over 15, consider microservices for the domains that change independently. **Which parts of the system change at different rates?** If the AI agent changes daily but the payment system changes monthly, they benefit from separate deployment. If everything changes at the same rate, separate deployment has no benefit. **Do you have the operational maturity?** Microservices require monitoring per service, logging per service, deployment per service, and debugging across services. If your team doesn't have these capabilities, microservices will slow you down, not speed you up. **Can you clearly define service boundaries?** If you can't articulate which data and which behavior belongs to which service, you'll draw the boundaries wrong. Wrong boundaries create services that are tightly coupled but separately deployed, which is the worst of both worlds. Start simple. Add complexity when the system demands it, not when the architecture diagram would look more impressive with more boxes. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).