Microservices Interview Questions

Bounded Context is the core pattern in DDD Strategic Design. It defines a boundary between a specific domain model (entities, values, business rules) and words (the vocabulary shared between developers and domain experts).

For example, the word “Client”. In a large business system, the same word can have different meanings. For example:

• “Client” in the Sales context is an entity with purchasing potential, lead history, and marketing score.
• “Client” in the Support context is an entity with a ticket history, service level agreement (SLA), and preferred contact channel.
• “Client” in the Billing context is an entity with a billing address, payment method, and invoice history information.

Bounded Context means to draw a line around one of these models, ensuring that within that line, ambiguity is eliminated and the model is coherent.

In microservices architecture, Bounded Context is the strongest guideline for defining the boundary of a microservice.

Characteristic	Bounded Context (DDD)	Microservices
Main Limit	Logical (the domain of language and model)	Physical (the boundary of deployment and execution)
Responsibility	Domain model consistency	Encapsulation of business logic and its state (data)
Ideally	Each microservice must encapsulate exactly a single Bounded Context.	Each Bounded Context becomes the boundary definition for a single microservice.

The second part of the question requires a real-life example demonstrating that the candidate understands the operational and technical consequences of violating this principle.

Ultimately, the question identifies whether the candidate views microservices as simply a technology (a bundle of containers connected through APIs) or as a design principle driven by business capabilities and domain knowledge. A developer who responds well demonstrates:

• Knowledge of Strategic DDD (Bounded Context, Ubiquitous Language).
• Ability to translate complex business models into sustainable service boundaries.
• Practical experience with the risks of coupling and technical debt inherent in not respecting the domain.

This is a fundamental software architecture question that tests the candidate’s ability to plan and execute one of the most complex tasks in engineering: decomposing a monolith.

The question is divided into three parts: (1) migration strategy (data and contracts), (2) the identification of anti-patterns, and (3) the explanation of why the Shared Database is considered a failure.

A candidate should describe a safe, incremental approach to avoid breaking the production system. The most common and robust pattern here is the Strangler Fig Pattern, which safely decomposes the monolith.

Here is how the Strangler Fig Pattern works:

1. Identify the Boundary Context: Use Domain-Driven Design (DDD) to map the monolith and identify the Bounded Contexts (e.g., Orders, Catalog, Billing).
2. Introduce a Facade/Proxy: A proxy or facade layer is placed between the clients and the legacy system.
3. Initial Routing: The facade initially routes most incoming requests to the existing legacy application.
4. Implement New Functionality: New functionalities or services are built and deployed outside the legacy application.
5. Incremental Routing Shift: As new services are developed, the facade gradually redirects more requests from the legacy system to the new services.
6. Decommission the Legacy System: Over time, as more functionalities are migrated, the legacy system’s responsibilities diminish. Once the new system handles all functionalities, the legacy application can be decommissioned. 

For the second and third parts, the Shared Database is the highest risk monolith decomposition anti-pattern and is often considered a failed state in microservices architecture.

Anti-Pattern	Description	Why is it high risk
Temporal and Logical Coupling	Occurs when two or more microservices access the same database schema.	It invalidates deployment autonomy.
Two-Phase Commit (2PC) protocol	Whether the services sharing the DB try to use an XA (two-phase commit) transaction to maintain consistency, or rely on low-level locks.	It invalidates scalability and resilience..
Model Inconsistency	The database becomes a universal domain model, where each service uses only a slice of the schema, but must live with the complexity and ambiguity of the others’ slices.	It leads to technical debt.

In short, this question assesses whether the candidate has experience in migration engineering and understands the theoretical foundations of service autonomy. A good candidate:

• Follows a recognized migration pattern (such as Strangler Fig).
• Prioritizes data decoupling (Database per Service) over communication decoupling.
• Correctly identifies the Shared Database as the main threat to autonomy. They demonstrate an understanding that data autonomy is the cornerstone of a sustainable microservices architecture.

For a startup with uncertain specifications, the initial choice is a risk-velocity assessment. The priority should be to maximize development speed and flexibility to change (agility), while minimizing initial operational complexity.

The decision should be weighed against the following factors, where the candidate must demonstrate an understanding of a startup’s priorities:

Factor	Modular Monolith (Advantages)	Microservices (Disadvantages/Risks)
Domain Uncertainty	Allows domain boundaries to be dynamically adjusted in code without major refactorings or data migrations (low cost of change).	Uncertainty leads to incorrect service boundaries, resulting in “chatty services” or coupling, which is expensive to correct.
Go-to-Market Speed	Simplified deployment and testing (a single application) accelerates Minimum Viable Product delivery.	Operational complexity (distributed CI/CD, observability) slows down the MVP and diverts valuable development resources.
Team Size	Ideal for small or single teams, as it eliminates the need to coordinate multiple deployments and repositories.	Requires a significant upfront investment in DevOps tools and a larger or more experienced team.
Operational Costs	Low operational cost (fewer servers, centralized monitoring, a single database).	High operational cost of distributed infrastructure, which may not be justifiable before the product proves its concept.

Prefer a candidate who initially chooses the Modular Monolith and articulates a clear plan for the transition (future migration to Microservices). This choice demonstrates maturity, awareness of trade-offs, and an understanding of the startup business context. They prioritize speed and deferral of complexity costs.

The Distributed Monolith is the architectural anti-pattern in which it is divided into microservices, but logically remains highly coupled and inflexible, like a monolith. It draws on all the flaws of microservices and none of their benefits. It arises when developers fail to respect autonomy and domain boundaries (Bounded Contexts). The main characteristics are:

1. Excessive Synchronous Coupling: Services depend on each other through chained synchronous HTTP calls (request-response). A failure or high latency in one service disrupts the entire chain.
2. Shared Database: The most critical dependency, where services share the same data store, undermining deployment autonomy.
3. Coordinated Deployment: The system requires multiple services to be deployed simultaneously (or in a specific order) to function, negating the independent deployment benefits of microservices.

In short, the Distributed Monolith introduces the complexity of the network without delivering the development speed and resilience benefits of microservices.

The question focuses on the difficulty of maintaining the ACID (Atomicity, Consistency, Isolation, Durability) properties of traditional database transactions when business operation is distributed across multiple services and databases.

In a monolith with a single database, atomicity (ACID) is guaranteed by local transactions. In microservices, if a business operation (e.g., placing an order that affects Payment, Inventory, and Billing) must be fully atomic, a locking or coordination mechanism that spans all involved services is required.

Long story short: if you prioritize strong consistency, the trade-off is coupling, which jeopardizes microservices’ speed, scalability, and performance. If you prefer scalability, performance, and speed, you can lose data consistency.

	Strong Consistency	Eventual Consistency
Definition	Everything is updated before the transaction is considered complete.	It may return an out-of-date value for a while, but the system guarantees that eventually all nodes will reflect the latest value.
Implementation	Distributed Transactions (2PC – Two-Phase Commit) (Generally avoided in microservices) or local transactions with heavy locks.	Saga pattern (Orchestration or Choreography) using asynchronous message queues (e.g., Kafka, RabbitMQ).
Speed and Latency	Slow. High latency due to the need for coordination and blocking between services.	Fast. Low latency because the initial operation (the command) is completed quickly.
Reliability	Low. A service failure blocks or rolls back the transaction for all services involved.	High. Services operate asynchronously; a service failure triggers a compensating action (rollback) rather than a cascading failure.

When to Choose Each

Strong Consistency is the only acceptable choice when financial security or the legality of the transaction requires that the data be 100% accurate, and the error cannot be compensated for later. For example, Bank Transfers or Tax Document Generation.

Eventual Consistency is the most appropriate choice (and often the only viable one) when the system needs high scale, high availability, and low latency more than consistency. For example, Order Processing (E-commerce), Updating Social Feeds, or View Counters.

This answer demonstrates that the candidate understands that migrating to microservices means adopting event-based transaction models (Sagas, Eventual Consistency) to achieve scalability and autonomy. They can:

• Identify the fundamental trade-off (CAP Theorem).
• Distinguish consistency models in terms of latency and resilience.
• Apply architectural knowledge to the business context, understanding when Strong Consistency is a non-negotiable requirement (critical financial/legal cases) and when Eventual Consistency is the scalability solution.

The Saga Pattern solves the distributed transaction problem, in which a business operation needs to update data in several independent services, each with its own database (Database per Service).

A Saga is a sequence of local transactions. Each local transaction updates the database of a single service and then publishes an event or sends a command to trigger the next step in the Saga.

If a local transaction fails, the Saga executes a series of compensating transactions that undo the changes made by the previous local transactions, ensuring that the system returns to a consistent state (although this may be the initial state, not the desired state of the operation).

The Saga Pattern can be implemented in two main ways: Choreography and Orchestration.

	Choreography	Orchestration
Main Mechanism	Domain Events. There is no central coordinator. Each service reacts to events emitted by other services.	Central Coordinator (Saga Orchestrator). A dedicated service or library (the Orchestrator) manages and directs the Saga.
Communication	Asynchronous, event-based.	It can be Synchronous Commands (API calls) or Asynchronous Commands (queues), but always directed by the Orchestrator.
Control Flow	Distributed, implicit. Services need to understand the context of the events they consume.	Centralized, explicit. The Orchestrator knows and dictates the complete order of the Saga.
Additional Steps	You need to modify the service that should be the next step, so that it starts consuming the event from the previous service.	You only need to modify the Orchestrator so that it includes a new command in the sequence.

The choice between Choreography and Orchestration is a trade-off between loose coupling and workflow visibility/maintenance.

Choreography is ideal when decoupling is the top priority, and orchestration is preferred when workflow complexity and maintainability are the primary concerns.

A candidate who describes the Saga Pattern and then details the trade-offs between Choreography and Orchestration demonstrates that:

• They understand how to solve the challenge of transactional integrity in distributed architectures.
• They are a pragmatic architect, capable of choosing the Saga style based on real metrics (flow complexity, number of services), prioritizing ease of maintenance (Orchestration for complex) or maximum decoupling (Choreography for simple).

This is a tricky question. Transactional integrity (funds must fully confirm or fully reverse) in a financial context is the definition of atomicity (A in ACID). In microservices environments, this is the opposite of what Eventual Consistency offers, and the most suitable pattern is Two-Phase Commit (2PC), despite its drawbacks in microservices.

2PC is a protocol that ensures that all participants (services/databases) in a distributed transaction either commit or roll back the transaction as a single atomic unit.

In an interbank transfer, money cannot temporarily “disappear.” Saga operates with the possibility of an initial failure, requiring a subsequent compensation transaction. This is unacceptable for bank balances where the error cannot be corrected (compensated) after the failure; it must be prevented at the time of the transaction.

2PC locks resources across all services until the outcome of the transaction is known to all. This ensures that any system reading the balance shortly after the transaction begins will see the correct state (whether old or new), never a temporarily inconsistent state.

On the other side, Saga is based on Eventual Consistency. If the function DebitService succeeds and the CreditService later fails, the Saga would require the DebitService to execute a compensation transaction (refund the debit). In a highly critical financial system, a debit cannot be executed if there is uncertainty about the credit. Temporary loss of funds is an unacceptable risk.

By choosing Two-Phase Commit (2PC), the candidate demonstrates an understanding that, for absolute and immediate integrity requirements (especially in finance), consistency is the non-negotiable pillar and should be prioritized over availability and performance.

Although 2PC creates a slow and block-prone distributed monolith, it is the only standard that satisfies the guaranteed atomic integrity requirement of a bank transfer. The key is to understand that, in this case, the cost of data inconsistency is much greater than the cost of performance latency.

This question shifts the focus from a high-risk financial scenario to a high-scale, delay-tolerant environment (e-commerce), where availability and latency are priorities. The candidate should identify the correct architecture and demonstrate an understanding of the Saga Pattern failure mechanism.

For an e-commerce platform that processes millions of simultaneous orders, where a small inconsistency is acceptable, but massive scalability and continuous high availability are critical, the ideal pattern is the Saga Pattern, which uses Eventual Consistency.

By identifying the Saga Pattern and focusing on Compensation, the candidate demonstrates an understanding of the balance of forces in high-scale architectures. They know that for high availability and low latency in e-commerce, Eventual Consistency is the only viable solution.

In addition, both the Saga Pattern and Compensation Transactions are engineering tools that mitigate the risk of this eventual consistency, ensuring that the integrity of the system is maintained, even if it takes a few seconds to resolve.

The Circuit Breaker is a crucial resilience standard. It’s a design pattern that prevents cascading failures in a distributed system by temporarily isolating a slow or failing service. The question assesses whether the candidate understands it as a fail-fast mechanism and can integrate it into the operations ecosystem (Observability).

 

It monitors outgoing calls to a dependent service and operates in three states:

State	Main Behavior	State Change Mechanism
Closed	The normal state. Requests are passed directly to the dependent service.	Switches to Open if the failure rate (or number of consecutive failures) exceeds a predefined threshold within a period of time.
Open	The Circuit Breaker stops requests to the dependent service immediately, returning a fast failure (e.g., HTTP 503) or a fallback response.	Switches to Half-Open after a configured timeout (recovery timeout), allowing the dependent service to recover.
Half-Open	Allows a small number of test requests to be sent to the dependent service.	If the test requests succeed, it switches back to Closed. If they fail, it immediately switches back to Open.

By preventing a healthy service (the caller) from overwhelming a sick service (the dependent) with requests, the Circuit Breaker allows the dependent service to recover, preventing cascading failure throughout the system.

A candidate who answers this question with the necessary depth demonstrates an experienced production engineer, capable of:

 

1. Applying resilience patterns to prevent cascading failures.
2. Understanding which resilience patterns require fine-tuning, based on real traffic profiles.
3. Ensuring Operational Excellence by integrating fault tolerance mechanisms (such as Circuit Breaker) with Observability (Metrics and Alerts), allowing on-call staff to react to failures as they occur.

This question assesses the candidate’s resilience arsenal and their ability to make engineering decisions that balance business priorities (user experience) and technical priorities (computational integrity). It’s divided into two parts: (1) the description of the complementary patterns to Circuit Breaker and (2) the justification of the failure handling strategy (fail fast vs. fallback).

In addition to the Circuit Breaker, here are the following patterns for managing predictable failures and ensuring system resilience:

Bulkhead isolates resources (e.g., thread pools or connection limits) allocated to each dependent service. If a dependent service slows down and consumes all resources (thread exhaustion), Bulkhead ensures that resources for other dependent services remain intact.

For example, if the Payment Service fails and exhausts its thread pool, the thread pool allocated to the Catalog Service is unaffected. It ensures that the user can continue browsing, even if they are unable to complete the purchase.

On the other hand, Retry allows the calling service to automatically retry a failed operation, assuming the failure is temporary and transient (e.g., an intermittent network issue or a momentary database lock). It should be used in conjunction with Exponential Backoff (increasing wait intervals between attempts) to prevent overloading the dependent service.

Finally, Timeout defines a maximum period of time that the calling service will wait for a response from the dependent service. It’s crucial to avoid resource exhaustion (thread exhaustion) in the calling service. If the dependent service is slow, Timeout ensures that the failure is recognized quickly, allowing the resource to be released or a fallback to be activated.

Now, the choice between “fail fast” and “fallback” depends directly on the Business Context and whether (1) the lost information is critical to integrity or (2) just necessary for the user experience.

Fallback

In an e-commerce microservices environment or a similar platform, a mature architect’s preferred strategy is usually to use Fallback with Caching. We prioritize Availability over Immediate Consistency (the cornerstone of Saga). Failing fast is bad for the user experience, as it results in an HTTP 5xx error.

Also, Fallback allows the application to gracefully degrade. If the Recommendation Service fails, the system displays default (fallback) products instead of an error page.

Fail Fast

Fail Fast is the only option when dependency failure affects transactional integrity or operational security. If the Payment Service is unable to communicate with the database to initiate the transaction, it must fail immediately.

The candidate who achieves this distinction demonstrates a thorough understanding of resilience architecture and risk prioritization. They understand a comprehensive set of patterns (Bulkhead, Retry, Timeout) for creating layers of defense.

Moreover, they demonstrate the ability to align technical decisions (fallback vs. fail fast) with business priorities (user experience in non-critical areas, integrity in critical areas). They opt for graceful degradation whenever possible, which is a hallmark of high-availability systems.

This is the ultimate Operational Excellence question, as it tests whether the candidate understands the concept of Observability as a triad (Logs, Traces, and Metrics) and whether they can import technical standards into a decentralized development environment. It’s the governance challenge of microservices.

Observability is the ability to infer the internal state of a complex system (in our case, microservices) from the data it generates externally. Remember: a single transaction in microservices can span dozens of different services.

The answer should explain how each component is insufficient in isolation, but powerful together:

Component	Main Function	Answers the Question
Centralized Logging	Captures all debug, info, warning, and error events from services and aggregates them into a single, searchable location (e.g., Elasticsearch).	“What happened at a specific point in time?” (Event detail).
Distributed Tracing	Tracks the complete journey of a single request across all service boundaries, correlating spans from different services using a single Trace ID.	“What is the root cause of latency or failure for a specific user?” (Request path and timing).
Real-Time Metrics Monitoring	Collects aggregated numerical data about system health (e.g., error rate, CPU latency, requests per second (RPS)).	“Where is the problem at scale (trend or anomaly)?” (Overall Health Indicator).

The candidate should cite widely recognized tools:

• Metrics: Prometheus (metrics collection) and Grafana (visualization and dashboards).
• Logging: ELK Stack (Elasticsearch for storage, Logstash for processing, and Kibana for visualization). Alternatively, the Loki/Tempo stack.
• Tracing: Jaeger or Zipkin (implementing the OpenTracing/OpenTelemetry standard).

Finally, decentralized microservices governance often leads to operational disorganization (logs in different formats, lack of trace IDs). The candidate should outline a governance plan to mitigate operational misalignment:

• Enforced Libraries:

1. 1. 1. Create an internal Standard Library (core). All microservice templates (in Java, Go, etc.) must import this library, which already contains the Tracing agent, the Log configurator (ensuring JSON format and mandatory fields such as service.name, environment, and trace.id), and the Metrics instrumenter (basic HTTP metrics).

• Communication Standards (Contracts):

1. 1. 1. Define as an architectural contract that the Trace ID must be propagated in all HTTP calls and queue messages. This ensures end-to-end traceability.

• CI/CD Verification (Quality Trigger):

1. 1. 1. Integration of observability tests into the CI/CD pipeline. For example, a build may fail if the code is not injecting the tracing agent correctly or if it is using a non-standard logger.

• Platform/Enabling Team:

1. 1. Designate a core team to own and maintain the observability infrastructure (Prometheus, Jaeger, ELK). This team trains development teams and provides dashboards and runbooks as services, encouraging adoption by making observability the path of least resistance.

The candidate demonstrates that they are a seasoned production engineer by detailing the synergy of the three pillars of Observability and, most importantly, presenting an Active Governance strategy (Standard Libraries and CI/CD Verification). They understand that the reliability of a complex system is an engineering responsibility that needs to be consistently enforced, not just a collection of tools. Moreover, they transform the “operational expense” of observability into a diagnostic benefit for the entire organization.

The question requires the candidate to demonstrate the ability to ensure zero downtime and backward compatibility in a dynamic production environment, addressing both deployment and contract management.

The candidate must demonstrate an understanding that the deployment strategy is a risk management decision.

Strategy	Mecanism	Benefits	Risks/Disadvantages
Blue/Green Deployments	Two identical infrastructures (Blue – old version; Green – new version). Traffic is instantly switched from Blue to Green (and vice versa) through a load balancer.	Zero Downtime: Rollback is instantaneous: simply revert the load balancer to the Blue environment.	Requires twice the infrastructure resources in parallel.
Canary Deployments	The new version (Canary) is released to a small subset of users and monitored by real-time metrics. If successful, the Canary is gradually expanded (e.g., 25%, 50%, 100%).	Lower Risk and Production Validation: Impacts fewer users and allows for real-world performance and behavior testing.	The deployment process is slower and requires advanced tools (e.g., Istio/Kubernetes) to split traffic.

Managing API compatibility is key to ensuring zero downtime during deployment, as new and old versions of the service can coexist.

The ideal choice in microservices is often versioning via custom headers or URI versioning. URI versioning (e.g., /api/v2/orders) is simple and explicit, but requires clients to change the URI. When migrating from V1 to V2, the fundamental principle is that V2 should be backward compatible with clients that still expect V1’s response. V2 must support the V1 API internally.

A canary deployment strategy ensures that traffic to the old version remains stable while traffic to the new version gradually increases. Only after traffic to V1 drops to zero can the V1 code be safely decommissioned (removed).

A candidate demonstrates a mature understanding of the microservice lifecycle by connecting deployment strategies with versioning. They understand that:

• The deployment choice is a risk management decision (high risk/fast with Blue/Green vs. low risk/slow with Canary).
• API Versioning is the communication contract that makes zero-downtime deployment possible, allowing versions to coexist in production. The candidate can plan not only the development of a service, but also its scalability.

In microservices, success depends not only on the code. This is the culminating question that assesses the candidate’s technical leadership and interpersonal skills, which are essential in a microservices environment.

The question doesn’t just seek a mentoring story, but requires the candidate to demonstrate the ability to break down advanced technical concepts (eventual consistency, tracing) and measure learning success.

The main disadvantage of microservices is complexity. If developers don’t understand this complexity, the system quickly becomes a “distributed monolith.” The candidate acting as a mentor demonstrates:

Mentorship Phase	Candidate Action Focus	Skill Assessed
Situation & Diagnosis	Identifying the mentee’s understanding problem.	Technical Diagnosis: Ability to identify the fundamental knowledge gap rather than the symptom (the error in the code).
Learning Framework (Action)	Conceptual Decomposition: The candidate not only answered, but structured the learning: a) Theory, b) Code Example, c) Tools.	Technical Didactics: Ability to simplify and provide a structured learning path, connecting theory (DDD) and practice (Observability).
Measurable Result	The mentee not only fixed the bug, but also mastered a new pattern (Example: “He implemented and documented the first Choreography Saga pattern, reducing the number of data inconsistency bugs by 15% in the following quarter”).	Mentoring Impact: Ability to prove that mentoring generated a quantifiable result for the team (reduced bugs, ownership of a new standard) and that the mentee became autonomous.

In short, the question reveals a candidate who is a force multiplier and a technical leader. They not only solve complex microservices architecture problems but also have the social skills to elevate the entire team.

 

The candidate should describe a rigorous and inclusive process to avoid bias and ensure all implications are considered.

1. Evaluation of Options and Proofs of Concepts (PoCs): Rather than simply debating, the candidate should describe the execution of time-limited PoCs for the 2-3 finalist technologies. This transforms the discussion from opinions to empirical data.
2. Multidisciplinary Workshops: Sessions with Development teams (ease of coding/integration), DevOps/SRE (deployment/operational complexity), and Security (vulnerabilities, compliance). This ensures that the trade-off is viewed from all organizational perspectives.
3. Risk Mapping (Opposition): Actively seeks opposing input. The candidate should have designated a “devil’s advocate” to defend the rejected option, ensuring that the risks of each choice (including the chosen one) are fully understood.

The candidate would also use a structured decision model, where business-critical criteria (e.g., “Ease of Hiring” or “Annual Operating Cost”) are weighted more heavily than lesser technical preferences.

Finally, a candidate must demonstrate the ability to translate technical complexity into terms of Business Value for different audiences.

This answer demonstrates that the candidate is more than a senior engineer; they are a leader with organizational impact. They have the insight to:

 

• Base difficult decisions on proof of concept and thoughtful risk analysis, rather than trends.
• Prioritize the company’s sustainability and scalability over short-term solutions.
• Translate technical complexity into clear implications for cost, risk, and velocity, aligning technical strategy with the company’s business objectives.

 

The scenario described is the physical manifestation of failed loose coupling. When a team breaks an API contract, it’s a symptom of failed governance and communication mechanisms. The candidate must demonstrate leadership in resolving the conflict without resorting to an oppressive central authority.

This answer demonstrates that the candidate is a technical governance leader, capable of:

• Resolving Conflicts (Interpersonal): Mediating high-pressure situations with temporary solutions.
• Enforcing Standards (Architectural Leadership): Using conflict as a “learning crisis” to integrate crucial standards (ACL and Versioning) into the teams’ daily practices.
• Maintaining Autonomy: Ensuring that the solution doesn’t centralize authority, but rather empowers teams (Team B to protect itself; Team A to refactor) to be truly autonomous within the contractual boundaries.

The candidate should detail how they moved the conversation from “APIs and Databases” to “Cost and Customer.”

Here are some examples:

“Imagine that the Stock Manager (Service A) and the Cashier (Service B) are different people. Instead of stopping the customer (latency), we allow the Cashier to process the transaction quickly. If the Cashier makes a mistake (payment fails), we send a ‘Correction Note’ (Compensation Transaction) to the Stock Manager. We pay the price of a 5-second delay (eventual) to ensure our checkout is never down (availability).”

“When you click ‘Buy,’ the ticket is booked immediately (high speed). We don’t stop to check 5 different systems. If a background system fails, you don’t get an error screen; you get an email within 10 minutes saying, ‘The transaction failed, but we’ve freed up the seat for you to try again.’ We traded 1-second absolute certainty for a fast experience with the possibility of a later error notification.”

The conclusion should not be “they got it,” but rather “they made a business choice.”