What are the trade-offs between eventual consistency and strong consistency in microservices?

Strong consistency guarantees that all reads see the latest write immediately, but it requires coordination (locks, 2PC) across services, which reduces availability and throughput — and is practically infeasible across independent databases. Eventual consistency means the system will converge to a consistent state given no new updates, but reads may temporarily return stale data. The practical trade-offs are significant: eventual consistency requires designing business processes that tolerate temporary inconsistency (e.g., showing "pending" payment status), implementing idempotency for safe retries, handling out-of-order events, and building compensating logic for conflicts. Strong consistency is appropriate for financial transactions within a single service boundary. Eventual consistency is the pragmatic choice for cross-service data — design your UX and business rules to accommodate it gracefully rather than fighting distributed systems physics.