The Postgres Migration That Changed Everything
Three years ago, I watched a team spend eight months migrating their user management system from MongoDB to PostgreSQL. They had all the right reasons. Better consistency guarantees. Mature tooling. A DBA who actually understood relational theory. The migration went smoothly until they realized they’d lost something critical: the ability to answer “why did this user’s permissions change last Tuesday?”
This wasn’t a failure of planning. It was a failure to recognize that data storage and data meaning operate on different timescales. Your database choice might change every few years, but the questions your business asks about state transitions remain constant. This distinction is driving a fundamental shift in how we think about distributed system persistence patterns.
Event Sourcing as Infrastructure, Not Feature
Event sourcing isn’t new, but its role is changing from application pattern to infrastructure primitive. Instead of storing current state, you store the sequence of events that led to that state. When Uber needs to reconstruct a ride’s pricing calculation from six months ago, they’re not querying a rides table. They’re replaying the sequence of location updates, surge multipliers, and promotional codes that generated the final fare.
The infrastructure implications are huge. Event stores become the source of truth, while traditional databases become derived views optimized for specific query patterns. PostgreSQL might handle your user lookups, Redis your session cache, and Elasticsearch your search queries. All three stay synchronized by consuming the same event stream. This isn’t eventual consistency by accident. It’s intentional decomposition of concerns.
What makes this pattern particularly compelling is its temporal resilience. Your current read model might be optimized for today’s queries, but next quarter’s analytics requirements won’t force another migration. You’ll build a new projection from the same event history. The cost of being wrong about schema design drops dramatically when schema becomes a view, not the foundation.
Command Query Responsibility Segregation Gets Serious
CQRS used to feel like academic architecture astronautics. That’s changing as read and write scalability requirements diverge at enterprise scale. At GitHub, code pushes generate events consumed by dozens of downstream systems: notification delivery, security scanning, deployment pipelines, and analytics aggregation. The write side focuses on accepting and ordering commands. The read side optimizes for query patterns that couldn’t exist when both lived in the same database.
The operational benefits compound over time. Write-side scaling becomes about event ingestion throughput. Read-side scaling becomes about projection maintenance and query optimization. These are fundamentally different problems requiring different tools and expertise. Your write infrastructure might run on Kafka and EventStore, while your read infrastructure spans PostgreSQL, BigQuery, and specialized vector databases for ML workloads.
This separation also enables failure isolation that traditional CRUD architectures can’t achieve. When GitHub’s code search experiences high latency, it doesn’t impact push operations. The event stream continues flowing while read projections catch up asynchronously. Downtime becomes partial and graceful rather than total and catastrophic.
Saga Patterns for Complex Transactions
Distributed transactions are where most microservice architectures reveal their true complexity. Two-phase commit doesn’t scale across network boundaries or organizational boundaries. Saga patterns are a more resilient alternative by breaking complex operations into sequences of local transactions, each compensatable if later steps fail.
Consider Shopify’s order fulfillment process. Charging payment, reserving inventory, scheduling shipping, and updating customer records happen across different services owned by different teams. A saga orchestrates these steps while maintaining consistency guarantees through compensation rather than locking. If shipping fails after payment succeeds, the saga triggers payment reversal and inventory unreservation automatically.
The implementation complexity shifts from runtime coordination to design-time planning. Each saga step must be idempotent and compensatable. This constraint forces better service boundaries and clearer failure semantics. Teams start thinking about business processes as sequences of state transitions rather than monolithic transactions. The result is more resilient systems that fail predictably and recover automatically.
Looking Forward: Orchestration Becomes Infrastructure
The patterns I’ve described share a common thread: they move complexity from application logic into infrastructure primitives. Event sourcing, CQRS, and sagas are becoming platform capabilities rather than application concerns. Kubernetes operators now manage event store clusters. Service meshes provide built-in saga coordination. Cloud providers offer managed event streaming with exactly-once delivery guarantees.
This infrastructuralization of distributed patterns will accelerate over the next five years. The signal is clear in how major platforms are changing. AWS EventBridge now handles event routing that used to require custom application logic. Google Cloud Workflows provides visual saga orchestration. Azure Service Bus has advanced message ordering and deduplication. These aren’t just convenience features. They’re infrastructure investments in patterns that have proven themselves at scale.
The speculation part: I expect we’ll see specialized databases optimized for event sourcing workloads become as common as traditional OLTP databases. Current event stores like EventStore and Apache Pulsar are early indicators, but purpose-built infrastructure for temporal data patterns will emerge as the default choice for new distributed systems.
Which of these patterns have you seen succeed or fail in production? The theoretical elegance of event sourcing and sagas matters less than their operational reality in your specific context.