Don’t forget to keep your eyes on the architectural concept of Command Query Record Separation (CQRS). When combined with event sourcing [1], there is a new un

Don’t forget to keep your eyes on the architectural concept of Command Query Record Separation (CQRS). When combined with event sourcing [1], there is a new unified architecture possible that solves the problem that microservices create by fragmenting data [2], and performant querying on data updating in real time. This architecture represents more complexity but increased flexibility. I recently saw this article about federated GraphQL [3], and while a cool idea and probably the ultimate solution (API composition), I expect that with network and physical boundaries between services still adding latency, we need materialized views as part of the architecture to compensate for the overhead of bringing together aggregate root objects from multiple systems. [1] https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/ https://www.confluent.io/blog/event-sourcing-cqrs-stream-pro... [2] https://microservices.io/patterns/data/cqrs.html https://microservices.io/patterns/data/cqrs.html [3] https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2 https://netflixtechblog.com/how-netflix-scales-its-api-with-...