cqrs journey guide

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

CQRS pattern

CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.

Context and problem

In traditional architectures, the same data model is used to query and update a database. That's simple and works well for basic CRUD operations. In more complex applications, however, this approach can become unwieldy. For example, on the read side, the application may perform many different queries, returning data transfer objects (DTOs) with different shapes. Object mapping can become complicated. On the write side, the model may implement complex validation and business logic. As a result, you can end up with an overly complex model that does too much.

Read and write workloads are often asymmetrical, with very different performance and scale requirements.

There is often a mismatch between the read and write representations of the data, such as additional columns or properties that must be updated correctly even though they aren't required as part of an operation.

Data contention can occur when operations are performed in parallel on the same set of data.

The traditional approach can have a negative effect on performance due to load on the data store and data access layer, and the complexity of queries required to retrieve information.

Managing security and permissions can become complex, because each entity is subject to both read and write operations, which might expose data in the wrong context.

CQRS separates reads and writes into different models, using commands to update data, and queries to read data.

• Commands should be task-based, rather than data centric. ("Book hotel room", not "set ReservationStatus to Reserved").
• Commands may be placed on a queue for asynchronous processing , rather than being processed synchronously.
• Queries never modify the database. A query returns a DTO that does not encapsulate any domain knowledge.

The models can then be isolated, as shown in the following diagram, although that's not an absolute requirement.

Having separate query and update models simplifies the design and implementation. However, one disadvantage is that CQRS code can't automatically be generated from a database schema using scaffolding mechanisms such as O/RM tools (However, you will be able to build your customization on top of the generated code).

For greater isolation, you can physically separate the read data from the write data. In that case, the read database can use its own data schema that is optimized for queries. For example, it can store a materialized view of the data, in order to avoid complex joins or complex O/RM mappings. It might even use a different type of data store. For example, the write database might be relational, while the read database is a document database.

If separate read and write databases are used, they must be kept in sync. Typically this is accomplished by having the write model publish an event whenever it updates the database. For more information about using events, see Event-driven architecture style . Since message brokers and databases usually cannot be enlisted into a single distributed transaction, there can be challenges in guaranteeing consistency when updating the database and publishing events. For more information, see the guidance on idempotent message processing .

The read store can be a read-only replica of the write store, or the read and write stores can have a different structure altogether. Using multiple read-only replicas can increase query performance, especially in distributed scenarios where read-only replicas are located close to the application instances.

Separation of the read and write stores also allows each to be scaled appropriately to match the load. For example, read stores typically encounter a much higher load than write stores.

Some implementations of CQRS use the Event Sourcing pattern . With this pattern, application state is stored as a sequence of events. Each event represents a set of changes to the data. The current state is constructed by replaying the events. In a CQRS context, one benefit of Event Sourcing is that the same events can be used to notify other components — in particular, to notify the read model. The read model uses the events to create a snapshot of the current state, which is more efficient for queries. However, Event Sourcing adds complexity to the design.

Benefits of CQRS include:

• Independent scaling . CQRS allows the read and write workloads to scale independently, and may result in fewer lock contentions.
• Optimized data schemas . The read side can use a schema that is optimized for queries, while the write side uses a schema that is optimized for updates.
• Security . It's easier to ensure that only the right domain entities are performing writes on the data.
• Separation of concerns . Segregating the read and write sides can result in models that are more maintainable and flexible. Most of the complex business logic goes into the write model. The read model can be relatively simple.
• Simpler queries . By storing a materialized view in the read database, the application can avoid complex joins when querying.

Implementation issues and considerations

Some challenges of implementing this pattern include:

Complexity . The basic idea of CQRS is simple. But it can lead to a more complex application design, especially if they include the Event Sourcing pattern.

Messaging . Although CQRS does not require messaging, it's common to use messaging to process commands and publish update events. In that case, the application must handle message failures or duplicate messages. See the guidance on Priority Queues for dealing with commands having different priorities.

Eventual consistency . If you separate the read and write databases, the read data may be stale. The read model store must be updated to reflect changes to the write model store, and it can be difficult to detect when a user has issued a request based on stale read data.

When to use CQRS pattern

Consider CQRS for the following scenarios:

Collaborative domains where many users access the same data in parallel. CQRS allows you to define commands with enough granularity to minimize merge conflicts at the domain level, and conflicts that do arise can be merged by the command.

Task-based user interfaces where users are guided through a complex process as a series of steps or with complex domain models. The write model has a full command-processing stack with business logic, input validation, and business validation. The write model may treat a set of associated objects as a single unit for data changes (an aggregate, in DDD terminology) and ensure that these objects are always in a consistent state. The read model has no business logic or validation stack, and just returns a DTO for use in a view model. The read model is eventually consistent with the write model.

Scenarios where performance of data reads must be fine-tuned separately from performance of data writes, especially when the number of reads is much greater than the number of writes. In this scenario, you can scale out the read model, but run the write model on just a few instances. A small number of write model instances also helps to minimize the occurrence of merge conflicts.

Scenarios where one team of developers can focus on the complex domain model that is part of the write model, and another team can focus on the read model and the user interfaces.

Scenarios where the system is expected to evolve over time and might contain multiple versions of the model, or where business rules change regularly.

Integration with other systems, especially in combination with event sourcing, where the temporal failure of one subsystem shouldn't affect the availability of the others.

This pattern isn't recommended when:

The domain or the business rules are simple.

A simple CRUD-style user interface and data access operations are sufficient.

Consider applying CQRS to limited sections of your system where it will be most valuable.

Event Sourcing and CQRS pattern

The CQRS pattern is often used along with the Event Sourcing pattern. CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically separate stores. When used with the Event Sourcing pattern , the store of events is the write model, and is the official source of information. The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views. These views are tailored to the interfaces and display requirements of the application, which helps to maximize both display and query performance.

Using the stream of events as the write store, rather than the actual data at a point in time, avoids update conflicts on a single aggregate and maximizes performance and scalability. The events can be used to asynchronously generate materialized views of the data that are used to populate the read store.

Because the event store is the official source of information, it is possible to delete the materialized views and replay all past events to create a new representation of the current state when the system evolves, or when the read model must change. The materialized views are in effect a durable read-only cache of the data.

When using CQRS combined with the Event Sourcing pattern, consider the following:

As with any system where the write and read stores are separate, systems based on this pattern are only eventually consistent. There will be some delay between the event being generated and the data store being updated.

The pattern adds complexity because code must be created to initiate and handle events, and assemble or update the appropriate views or objects required by queries or a read model. The complexity of the CQRS pattern when used with the Event Sourcing pattern can make a successful implementation more difficult, and requires a different approach to designing systems. However, event sourcing can make it easier to model the domain, and makes it easier to rebuild views or create new ones because the intent of the changes in the data is preserved.

Generating materialized views for use in the read model or projections of the data by replaying and handling the events for specific entities or collections of entities can require significant processing time and resource usage. This is especially true if it requires summation or analysis of values over long periods, because all the associated events might need to be examined. Resolve this by implementing snapshots of the data at scheduled intervals, such as a total count of the number of a specific action that has occurred, or the current state of an entity.

Example of CQRS pattern

The following code shows some extracts from an example of a CQRS implementation that uses different definitions for the read and the write models. The model interfaces don't dictate any features of the underlying data stores, and they can evolve and be fine-tuned independently because these interfaces are separated.

The following code shows the read model definition.

The system allows users to rate products. The application code does this using the RateProduct command shown in the following code.

The system uses the ProductsCommandHandler class to handle commands sent by the application. Clients typically send commands to the domain through a messaging system such as a queue. The command handler accepts these commands and invokes methods of the domain interface. The granularity of each command is designed to reduce the chance of conflicting requests. The following code shows an outline of the ProductsCommandHandler class.

The following patterns and guidance are useful when implementing this pattern:

Data Consistency Primer . Explains the issues that are typically encountered due to eventual consistency between the read and write data stores when using the CQRS pattern, and how these issues can be resolved.

Horizontal, vertical, and functional data partitioning . Describes best practices for dividing data into partitions that can be managed and accessed separately to improve scalability, reduce contention, and optimize performance.

The patterns & practices guide CQRS Journey . In particular, Introducing the Command Query Responsibility Segregation pattern explores the pattern and when it's useful, and Epilogue: Lessons Learned helps you understand some of the issues that come up when using this pattern.

Martin Fowler's blog posts:

• What do you mean by "Event-Driven"?

Related resources

Event Sourcing pattern . Describes in more detail how Event Sourcing can be used with the CQRS pattern to simplify tasks in complex domains while improving performance, scalability, and responsiveness. As well as how to provide consistency for transactional data while maintaining full audit trails and history that can enable compensating actions.

Materialized View pattern . The read model of a CQRS implementation can contain materialized views of the write model data, or the read model can be used to generate materialized views.

Submit and view feedback for

Additional resources

Project "a CQRS Journey"

For the things we have to learn before we can do them, we learn by doing them. ~aristotle.

The journey is now complete . Get the final deliverables here .

The Microsoft patterns & practices team is a group of engineers (developers, testers, program managers), designers, and technical writers who produce guidance to help the larger community build solutions. With this project, we hope to provide you with a map that will help you to find your own way with the Command and Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns and related techniques.

There will be two, closely related, deliverables from this project: the source code for a complete, working reference implementation (an end-to-end sample app) that illustrates the key concepts, patterns, and approaches related to CQRS & ES, and a written guide to accompany the code, provide explanations, context, and references to other relevant material.

The reference implementation will be a conference management system that you will be able to easily deploy and run in your own environment. This will enable you to explore and experiment with a realistic application built following a CQRS-based approach.

• This project values open, standards-based development
• We value the great work already available from others and intend to thank existing thought-leaders through attribution
• This work should happen in the open so everyone is able to follow along
• We would like to help foster a community of practice and build consensus within the community
• This project represents a conversation not a dictation
• We would like to meet the community where it is - using what it’s using
• The guidance should be based on the best thinking available but also the scenarios customers care about

We hire experts, developers, testers, and writers to augment our team of full-time employees to build these deliverables. We do so using agile/Scrum team practices that operate on fortnightly sprints. At the end of each sprint we hold calls with a group of advisors to demo the new stuff, discuss decision points, and get feedback on our direction. This feedback is crucial to our success.

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

CQRS Journey Guide converted to PDF for eBook reading.

slashdotdash/cqrs-journey-pdf

Name already in use.

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more about the CLI .

• Open with GitHub Desktop
• Download ZIP

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Cqrs journey => pdf.

Ruby script for generating PDFs from the Microsoft patterns & practices CQRS Journey documentation .

This is entirely unofficial and is in no way endorsed by Microsoft or the patterns & practices team. However I found it useful to create a PDF from the documentation to allow reading on my iPad.

Download a pre-generated copy of the final CQRS Journey document.

• CQRS Journey (PDF)

Dependencies

Uses the gimli Ruby gem for converting markup, such as Markdown formatted text, to PDF. Gimli uses PDFKit for PDF generation, which itself is a thin wrapper around wkhtmltopdf .

Pygments the Python syntax highlighter is optionally used to prettify the C# source code.

Requires git for cloning/pulling the CQRS doc repository from github.

Fonts used are Calluna and Calluna Sans ; both are freely available to download.

Install dependencies.

Optionally, install Pygments.

Clone the CQRS documentation repository.

Generate PDFs of the README, Journey and Reference documents.

CQRS Journey documentation is © 2012 Microsoft. All rights reserved.

• Ruby 100.0%

• Kindle Store
• Kindle eBooks
• Computers & Technology

Promotions apply when you purchase

These promotions will be applied to this item:

Some promotions may be combined; others are not eligible to be combined with other offers. For details, please see the Terms & Conditions associated with these promotions.

Buy for others

Buying and sending ebooks to others.

Additional gift options are available when buying one eBook at a time.  Learn more

These ebooks can only be redeemed by recipients in the US. Redemption links and eBooks cannot be resold.

Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required .

Read instantly on your browser with Kindle for Web.

Using your mobile phone camera - scan the code below and download the Kindle app.

Image Unavailable

• To view this video download Flash Player

Follow the authors

Exploring CQRS and Event Sourcing (Microsoft patterns & practices) Kindle Edition

• Kindle $7.42 Read with our free app
• Paperback $29.10 - $52.99 7 Used from $25.11 2 New from $52.99
• Print length 376 pages
• Language English
• Sticky notes On Kindle Scribe
• Publication date July 20, 2012
• File size 12770 KB
• Page Flip Enabled
• Word Wise Not Enabled
• Enhanced typesetting Enabled
• See all details

Customers who read this book also read

Editorial Reviews

Product details.

• ASIN ‏ : ‎ B00EUGIRQY
• Publisher ‏ : ‎ ; 1st edition (July 20, 2012)
• Publication date ‏ : ‎ July 20, 2012
• Language ‏ : ‎ English
• File size ‏ : ‎ 12770 KB
• Simultaneous device usage ‏ : ‎ Unlimited
• Text-to-Speech ‏ : ‎ Enabled
• Screen Reader ‏ : ‎ Supported
• Enhanced typesetting ‏ : ‎ Enabled
• X-Ray ‏ : ‎ Not Enabled
• Word Wise ‏ : ‎ Not Enabled
• Sticky notes ‏ : ‎ On Kindle Scribe
• Print length ‏ : ‎ 376 pages
• #286 in Computer Systems Analysis & Design (Kindle Store)
• #773 in Computer Systems Analysis & Design (Books)
• #6,055 in Software Design, Testing & Engineering (Books)

About the authors

Grigori melnik.

Dr. Grigori Melnik is a Director of Product Management at Splunk focusing on the Splunk Developer Platform (http://dev.splunk.com). He helps software engineers embrace good practices and fosters software craftsmanship.

Formerly at Microsoft, he produced patterns & practices components as well as architectural guidance to address common cross-cutting software engineering concerns. He also drove the Design for IT Efficiency imperative. Prior to that, he was a researcher and developer -- long enough ago to remember the joy of programming in Fortran.

He is an Associate Editor-in-Chief of the IEEE Software magazine and an Adjunct Professor of Computer Science at the University of Calgary, Canada. He speaks around the world on the topics of operational and business intelligence, code reuse, cloud computing, agile methods, and software testing. He holds a Ph.D. in Computer Science from the University of Calgary.

Contact him at http://twitter.com/gmelnik

Julian Dominguez

Julián Domínguez is a software developer on the Microsoft patterns & practices team, producing written and code-based guidance for .NET developers. He has been a contributor on several projects with this team, including the CQRS Journey, Semantic Logging Application Block, Prism, Enterprise Library 6, and Windows Azure Autoscaling Block.

Blog: http://blogs.msdn.com/b/jdom/

Dominic Betts

Dominic is currently a senior content developer at Microsoft where he creates technical content for Azure IoT services such as Azure IoT Central. Dominic’s previous projects include working with the Microsoft patterns and practices team to produce developer, architect, and IT Pro focused guidance on developing solutions for Windows, Windows Phone, and the cloud. Dominic has created and taught courses covering a range of topics such as BizTalk, SQL Server, ASP.NET, .NET Threading, Enterprise Java, and assembly language. Dominic was the UK's IT Trainer of the Year in 2003.

Customer reviews

Customer Reviews, including Product Star Ratings help customers to learn more about the product and decide whether it is the right product for them.

To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzed reviews to verify trustworthiness.

• Sort reviews by Top reviews Most recent Top reviews

Top reviews from the United States

There was a problem filtering reviews right now. please try again later..

Top reviews from other countries

• Amazon Newsletter
• About Amazon
• Accessibility
• Sustainability
• Press Center
• Investor Relations
• Amazon Devices
• Amazon Science
• Start Selling with Amazon
• Sell apps on Amazon
• Supply to Amazon
• Protect & Build Your Brand
• Become an Affiliate
• Become a Delivery Driver
• Start a Package Delivery Business
• Advertise Your Products
• Self-Publish with Us
• Host an Amazon Hub
• › See More Ways to Make Money
• Amazon Visa
• Amazon Store Card
• Amazon Secured Card
• Amazon Business Card
• Shop with Points
• Credit Card Marketplace
• Reload Your Balance
• Amazon Currency Converter
• Your Account
• Your Orders
• Shipping Rates & Policies
• Amazon Prime
• Returns & Replacements
• Manage Your Content and Devices
• Your Recalls and Product Safety Alerts
• Conditions of Use
• Privacy Notice
• Your Ads Privacy Choices

• Articles Architect career Architectural design strategy Architecture patterns Architecture tools Cloud computing Enterprise architecture design Kubernetes Security
• Portfolio Architecture

An illustrated guide to CQRS data patterns

%t min read | by Bob Reselman

Photo by Teo Duldulao

Today millions of users can be reading and writing data into applications in near simultaneity. The variety of such applications is broad, well beyond the traditional high volume scenarios typically found in banking and other financial applications. New approaches are needed.

One such approach is the Command Query Responsibility Segregation (CQRS) pattern.

Take the CQRS interactive tutorials on Katacoda

In addition to the information provided in this article, we’ve published a set of three tutorials on the Katacoda interactive learning environment that will help you understand the CQRS pattern at an operational level.

The Katacoda learning environment provides an interactive virtual machine where you can execute the commands and techniques described in the tutorials directly in a terminal window. The Katacoda environment allows you to learn by doing!

You can access the tutorials at the following links:

• Part 1-Examining a Single Source Database Architecture
• Part 2-Implementing the CQRS Pattern
• Part 3-Taking an Event-Driven Approach to CQRS

What is CQRS?

The Command Query Responsibility Segregation pattern is, as the name implies, a software design pattern that separates command activities from query activities. In CQRS parlance, a command writes data to a data source. A query reads data from a data source. CQRS addresses the problem of data access performance degradation when applications running at web-scale have too much burden placed on the physical database and the network on which it resides.

In the old days, before the emergence of ubiquitous computing brought about by the internet, having a single database be the single source for read and write activities in an application was a reasonable approach to data access. (See Figure 1, below.)

Figure 1 : In the days before the commercialized internet, reading and writing data to a single database was commonplace

If performance started to degrade, you could always convert the single database into a database cluster and thus spread access activities across the cluster. However, as long as the cluster was exposed as a single point on the network, there was still the risk of high latency due to the bottleneck around that access point. All read requests (the query) and all write requests (the command) went to the same target.

The benefit that CQRS brings to data design is that it separates read and write behaviors in the application logically and physically. (See Figure 2, below)

Figure 2 : The underlying principle of CQRS is to completely separate write activity from read activity within the underlying application architecture

In a single-source data design, one database is the target of both read and write activity. When the CQRS pattern is used, read and write activity is separated among a variety of data sources. Also, each data source can be a database technology that is best suited for the particular need. For example, the best technology for storing write data might be a relational database such as Postgres or even DB2 on a mainframe. On the other hand, should the forces driving read behavior have to do with displaying hierarchical data on an eCommerce site, for example, using a document database such as MongoDB to store read data and view it makes sense.

While following the CQRS pattern to separate write storage from read storage provides a high degree of flexibility and efficiency for applications operating at a web-scale, implementing the pattern comes with a fundamental challenge that needs to be addressed in any situation. The challenge is data synchronization.

Addressing the challenge of data synchronization

As mentioned above, essential to the concept of CQRS is the notion of separating read behavior from write behavior. Under CQRS, an application will save data to one distinct data source and read data from another. However, given that read and write data sources are separate and isolated from each other, CQRS only works if the data is consistent among all data sources. In other words, if I have an eCommerce application that adds an order object to the write database, the information in that order had better show up somewhere in the read database in an accurate and timely manner. If not, the entire application is at risk of offering up inaccurate data and, thus, not being of much value.

Ensuring data consistency among the entire array of database technologies in a CQRS architecture is essential. The questions then become not only, how do you do it but also, how do you do it well?

First, let’s take a look at the way that works but has an undesirable side-effect. Then, let’s look at a more optimal approach.

Avoiding a common mistake

One way to implement data consistency under CQRS is to create intelligence in the application to inspect an incoming request and apply CQRS logic accordingly. Figure 3 below shows an example of this idea.

Figure 3 : Putting data routing within the scope of an HTTP request creates a tightly bound architecture that will be difficult to refactor

Figure 3 above is an example of a fictitious API that supports read (a.k.a. query) behavior via an HTTP GET request on a single endpoint. Write (a.k.a. command) behavior is supported by an HTTP POST against that same endpoint.

When a read query comes in, the HTTP service retrieves the data from the Read database. However, when write data comes in via the POST request, things get a little more involved. The POST logic makes two writes, one to the Write DB as expected and one to the Read DB. Thus, data consistency among the data sources is achieved. That’s the good news. The bad news is that the technique has incurred risk and technical debt.

The biggest risk is one of transactional failure. There is an underlying assumption in play that the HTTP POST write activities that attempt to add data to both the Write DB and the Read DB are successful. As it stands in the Figure 3 code, there is no failure check on either write and no fallback behavior to save the incoming data on failure. Obviously, this problem needs to be addressed in order to have a viable implementation of CQRS. Yet, there is another problem, and this one is architectural.

Putting the logic for implementing CQRS directly in the web server makes the application brittle. A fundamental principle of application design is the clear separation of concerns. Putting CQRS logic in the web server violates the principle.

The concern of the web server is to accept and route requests onto relevant logic. The concern of CQRS is to separate read and write activities in the application’s data access framework. Mixing these two creates a technical debt level that will be hard to pay back when the time comes.

Thankfully, there is a better way.

Using event-driven data persistence

A better way to implement CQRS is to use the mediator pattern in conjunction with an event-driven data persistence architecture. Let’s start with the latter.

Event-driven data persistence is a technique in which events are raised in accordance with a given application’s purpose, and the data associated with the given event is consumed by interested parties. For example, at the conceptual level, let’s imagine that we have an eCommerce API that accepts orders. A user posts a request that has order information. The API receives the order information and packages it up into a structured message that describes an event, OnNewOrder , as shown below in Listing 1.

Listing 1 : An example of an event message

The API publishes that message to a message broker such as Kafka. Those parties interested in information around an OnNewOrder event consume that message and process it according to their purpose.

The value of using event-driven data persistence is that the technique creates a high degree of independence among the various data sources in play in a given application. Each component in an application does only what it’s supposed to do. There is no mixing and matching.

However, to support event-driven data persistence under CQRS, there still needs to be intelligence that can mediate read and write behavior for incoming requests. Also, because data will be dispersed throughout the application in a variety of asynchronous messages that correspond to particular events, there needs to be a mechanism to store all the data for all the events generated. This storage mechanism needs to store the data for a long time, on the order of years. This way, if things go awry and read and write data goes out of sync or the data in a data source is destroyed, a sole point of truth—the event store—can be used to reconstitute the system to the last known, good state.

Let’s take a look at how this works.

Taking an event-driven approach to CQRS

Figure 4 below illustrates a data architecture that implements CQRS using the mediator pattern. The first thing to notice is that all requests, both commands to add data to the application and queries to read data from the application, pass from the application’s web server onto a component named Mediator .

Figure 4 : Using a Mediator in an event-driven architecture provides independence and flexibility

The purpose of the Mediator is to distinguish read and write requests and then route the request accordingly. If the request is a write command, that data is forwarded onto a component called a WriteDataManager . If the request is a read query, it is retrieved from a component called ReadDataManager .

The purpose of WriteDataManager is to connect to a write database and add the data in the request. Also, upon adding data to the write database, the WriteDataManager will publish an event, OnNewOrder , to a message broker to which it is bound. At this point, WriteDataManager has done its work. The actual consumption of the data associated with the OnNewOrder event is of no concern to WriteDataManager . Its job is to add data to its data store and generate an event when data is added.

When the message broker receives an OnNewOrder event message, it does two things. First, the message broker stores the data associated with the event in its internal event data store. This creates a permanent record of the event that can be used for audit and failure recovery purposes.

Second, the message broker passes the message to a message queue to which interested parties are subscribed. Interested parties consume the message and act on it according to their purpose.

In the case of the read data source, as mentioned previously, that functionality is represented by the component named ReadDataManager . ReadDataManager subscribes to a queue on the message broker to receive OnNewOrder event messages. When an OnNewOrder message is received, ReadDataManager saves the relevant information in the event message to its data store. At this point, both data as represented by both WriteDataManager and ReadDataManager is consistent. Thus, the intention of CQRS has been fulfilled in a way that is loosely coupled yet reliable and verifying between data sources.

Putting it all together

The Command Query Responsibility Segregation pattern is a valuable design technique that is well suited to applications that need to support a high volume of requests made against very big data sources. Separating read from write behavior improves system performance overall. And, it allows systems to scale up quickly when functionality or data structures need to be added. When used in conjunction with the mediator pattern, CQRS makes the system more flexible and easier to refactor.

However, while CQRS is powerful, it is not simple. Separating data according to purpose means that there is always a risk of compromised data consistency either due to varying degrees of latency on the network or episodic system failure. Thus, implementing CQRS using an event-driven data persistence architecture in which the system’s message broker can store every message received for a very long time is a sensible way to go.

CQRS can increase system performance and efficiency. The trick is to make sure that the underlying application architecture in which it is implemented is loosely coupled and can be reconstituted to the last known good state in the event of catastrophic failure.

Bob Reselman

Bob Reselman is a nationally known software developer, system architect, industry analyst, and technical writer/journalist. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX

Privacy Statement

• IEEE CS Standards
• Career Center
• Subscribe to Newsletter
• IEEE Standards

• For Industry Professionals
• For Students
• Launch a New Career
• Membership FAQ
• Membership FAQs
• Membership Grades
• Special Circumstances
• Discounts & Payments
• Distinguished Contributor Recognition
• Grant Programs
• Find a Local Chapter
• Find a Distinguished Visitor
• Find a Speaker on Early Career Topics
• Technical Communities
• Collabratec (Discussion Forum)
• Start a Chapter
• My Subscriptions
• My Referrals
• Computer Magazine
• ComputingEdge Magazine
• Let us help make your event a success. EXPLORE PLANNING SERVICES
• Events Calendar
• Calls for Papers
• Conference Proceedings
• Conference Highlights
• Top 2023 Conferences
• Conference Sponsorship Options
• Conference Planning Services
• Conference Organizer Resources
• Virtual Conference Guide
• Get a Quote
• CPS Dashboard
• CPS Author FAQ
• CPS Organizer FAQ
• Find the latest in advanced computing research. VISIT THE DIGITAL LIBRARY
• Open Access
• Tech News Blog
• Author Guidelines
• Reviewer Information
• Guest Editor Information
• Editor Information
• Editor-in-Chief Information
• Volunteer Opportunities
• Video Library
• Member Benefits
• Institutional Library Subscriptions
• Advertising and Sponsorship
• Code of Ethics
• Educational Webinars
• Online Education
• Certifications
• Industry Webinars & Whitepapers
• Research Reports
• Bodies of Knowledge
• CS for Industry Professionals
• Resource Library
• Newsletters
• Women in Computing
• Digital Library Access
• Organize a Conference
• Run a Publication
• Become a Distinguished Speaker
• Participate in Standards Activities
• Peer Review Content
• Author Resources
• Publish Open Access
• Society Leadership
• Boards & Committees
• Special Technical Communities
• Local Chapters
• Governance Resources
• Conference Publishing Services
• Chapter Resources
• About the Board of Governors
• Board of Governors Members
• Diversity & Inclusion
• Open Volunteer Opportunities
• Award Recipients
• Student Scholarships & Awards
• Nominate an Election Candidate
• Nominate a Colleague
• Corporate Partnerships
• Conference Sponsorships & Exhibits
• Advertising
• Recruitment
• Publications
• Education & Career

A Comprehensive Guide to CQRS Data Pattern (Plus Common Mistakes to Avoid)

This is particularly true for building and maintaining applications as part of your business model. This is where CQRS data patterns come in as an alternative to traditional CRUD patterns.

But, what is CQRS, and how can you use it? In this article, we’ll take a look at exactly that and give you some advice on avoiding some common mistakes.

Want More Tech News? Subscribe to ComputingEdge Newsletter Today!

What is CQRS?

CQRS is the industry shorthand used for Command Query Responsibility Segregation patterns. This means that CQRS patterns are software design patterns that separate queries and commands. They are typically used for data storing applications in the cloud.

Put simply, the answer to the question ‘what is CQRS?’ is that CQRS data patterns separate the operations for writing and reading data.

• Query: a function that reads new data
• Command: a function that writes or updates data

Practically, commands translate into actions within your application server and are always written as imperative action verbs. For example, a business offering virtual call center services might need to command code that instructs the application server to {delete} old data or {install} new add-ons.

Queries typically read, process, and transfer data for display. They are what makes the command possible, as they read the data written by the command and translate it appropriately.

CQRS data patterns are typically used instead of a traditional system known as create, read, update, and delete or CRUD. This is a more simplistic way of processing data and should generally be used as a first port of call, but it isn’t suitable for every business.

You should be asking yourself ‘what is CQRS?’ and looking into it if your application is considering scaling regularly or needs frequent updates.

Why use CQRS Patterns?

Most traditional software systems use the same data model to write and read data. This can work well for simple systems but, as the system grows more complicated, you might find that you struggle to control and track your data sets.

These are some ways in which traditional data models can cause problems in complex data stores:

• Different interpretations: the query and command functions may result in different interpretations of the same data and cause disruptions in your data flow.
• Data contention: the data may become scrambled if multiple operations are performed on the same set at the same time.
• Security: pieces of data are subject to both reading and writing processes within the same set, which brings the potential for incorrectly exposing the data.

One of the major benefits of CQRS patterns comes from event sourcing.

With separate query and command operations, it’s much simpler to create a chronological log of all changes to your server and reconstruct a past state in the event of a critical error. Other benefits include:

• Widening user access: CQRS data patterns can be very useful for data sets where many users are accessing and processing it at the same time. It can minimize conflicts with merging data and allow multiple users to make changes to data at the same time, promoting productivity and avoiding workflow disruptions.
• Read/write imbalance: data is often read a lot more often than it’s written. A CQRS data pattern allows you to scale up the read data processes while leaving the written data processes the same if you’ve got a large imbalance to account for.
• Keep up with industry regulations: because of the potential for data sharing and leaks, the technology industry regulations are updated often. By being able to make quick updates to your system, you can be sure to always be within these rules when operating.

Try to keep up to date with any developments in the field of data automation and patterns through software publications , and make sure to regularly review your skills.

Common Mistakes To Avoid

Any software design process comes with potential pitfalls, particularly if you haven’t worked with this kind of pattern before. These are some of the more common mistakes that you might make with CQRS patterns and how to avoid them.

1. Expecting Too Much

CQRS patterns are useful tools, but they’re not a fix-all solution. They can be complex, and they require a high level of expertise to manage properly.

They should only be used in certain situations to make sure that you get the best result from your efforts. These situations are ones where you can use CQRS patterns successfully:

• Your system evolves frequently or uses frequent updates – very important, as otherwise the system may become too complex and result in too much stale data.
• You’re struggling to scale up with other pattern methods
• Your domain is query-oriented
• You collaborate with other teams or servers
• You have the capacity to store stale data

The solution: thankfully, the solution here is simply to know when to apply CQRS patterns to your software and when another solution would work better.

2. Stale Data

Stale data can be a problem when it comes to CQRS data patterns.

If you’re unfamiliar with the concept, stale data is what occurs when data is read and processed and then altered in some way. When the system attempts to retrieve processed data and is only able to retrieve the old configuration of the data, this is said to be stale data.

Because command and query functions have been separated in a CQRS pattern, the read data may not be updated and may end up being stale. To avoid this, make sure to update the read data alongside the written data.

3. Complexity

CQRS systems can be the solution to a lot of different issues thrown up by traditional data patterns. However, they can also lead to increased complexity.

This is especially true if your system includes an event sourcing pattern. In this case, the sequence of events/updates often take the place of actual written data, which helps to optimize performance. The read data is translated into materialized views of the data stored in the read data store.

One of the issues you might encounter here is eventual consistency. The complexity of the system means that there will initially be a delay between generating the event sequence and the data being updated accordingly.

To avoid complexity becoming a problem, be sure to be consistent in updating your data and checking the stores for faults and data loss.

4. Updating unnecessarily

You should consider the necessity of CQRS at every stage of implementation. It can be hugely beneficial but time-consuming to implement, so you need to be sure that it is the best course of action before doing this.

CQRS is most suitable for data sets and systems that require continuous and frequent updates, like a communication platform or an application that is compatible with existing devices.

If your business does not do this, you might be better off upgrading your traditional data model.

On the other hand, you may still be using traditional data patterns that aren’t working for you. You might need CQRS without knowing it! For example, you may discover that you need to update your application server more often than planned. Consider reviewing your business and similar ones that have received ISO accreditation to identify any glaring issues with your application.

One of the ways that you can work out if you need to update your application more often is by collecting analytics data. For example, a Google Analytics exit rate or other customer satisfaction metrics concerning length and frequency of use. This way, you can identify the areas that might benefit from more frequent updates allowed by CQRS patterns.

5. Poor communication

To finish, a quick reminder to communicate! CQRS patterns can be complicated to implement and require a lot of teamwork, so remember to keep your team in the loop of what you’re doing. You’ll need to be able to explain to your team what CQRS is and how to integrate it.

Maintaining your communication infrastructure is key to this, particularly for smaller businesses that might lack the financial capital of larger ones. Understanding the best multi-line phone system for small business and the best way to store your plans and progress are both great first steps toward top-tier communication in your software design team!

Using CQRS can be complex and requires a deep understanding of your role and the goals of your application to carry out properly.

Part of this preparation might be to join a software engineering community and see what others are saying about this process and how best to manage complications or errors. Above all, be sure to understand the common mistakes that come with considering and implementing CQRS data patterns and how to get around them!

About the Writer

Recommended by IEEE Computer Society

How to Make Decision Trees to Better Utilize Your Current Data

The Power of Green Communication (and How it Benefits Businesses)

Break Down Barriers to Open Source Success with the Ultimate DX Support Team

How To Accelerate AWS Lambda Performance

Exploring the Differences Between Parallel and Distributed Computing

The Future of Cybersecurity in an AI-Driven World

Sign up for our newsletter.

EMAIL ADDRESS

IEEE COMPUTER SOCIETY

• Board of Governors
• IEEE Support Center

DIGITAL LIBRARY

• Librarian Resources

COMPUTING RESOURCES

• Courses & Certifications

COMMUNITY RESOURCES

• Conference Organizers
• Communities

BUSINESS SOLUTIONS

• Conference Sponsorships & Exhibits
• Digital Library Institutional Subscriptions
• Accessibility Statement
• IEEE Nondiscrimination Policy
• XML Sitemap

©IEEE — All rights reserved. Use of this website signifies your agreement to the IEEE Terms and Conditions.

A not-for-profit organization, the Institute of Electrical and Electronics Engineers (IEEE) is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity.

CQRS Journey Guide

Cqrs_journey_guide.

User Manual:

Navigation menu

• Upload a User Manual

Versions of this User Manual:

• Download & Help
• User Manual
• Discussion / Help
• © 2023 UserManual.wiki

When should you use CQRS?

• Last updated: July 5, 2022

RisingStack's services:

Full-Stack Development & Node.js Consulting

DevOps, SRE & Cloud Consulting

Kubernetes Consulting

24.7 Node.js Support

Infrastructure Assessment & Code Reviews

• We are hiring NEW!

Sign up to our newsletter!

Join 150K+ monthly readers.

In-depth articles on Node.js, Microservices, Kubernetes and DevOps.

Node.js Experts Here!

Custom solutions for lightning-fast, real-time web apps.

In this article:

The formerly exotic architectural pattern CQRS is becoming increasingly suitable for the masses. However, too many developers still know the approach only from hearsay, and can hardly estimate whether it is worth the effort.

Until a few years ago, when searching for  CQRS , one was asked by Google whether one might have meant the search term  cars . In the course of time, this has developed into a joke that developers familiar with CQRS actually pronounce the acronym  CQRS  like  cars . But what is CQRS anyway?

One of the simplest and most frequently cited explanations is that CQRS is in principle the same as the design pattern  CQS , applied to the architectural level of an application. This comparison is quite correct, but for someone who is not yet familiar with CQRS, it is difficult to understand and therefore hardly helpful.

The fundamental question must therefore first of all be what the design pattern CQS actually is. Bertrand Meyer’s approach separates the methods of objects into two categories: Commands and queries. This is where the name comes from, because CQS stands for  Command Query Separation .

Commands and queries

A  command  is a method that either changes the state of an object, has side-effects, or fulfills both criteria at the same time. However, a command deliberately does not return a return value, which is why it cannot return any information about the state of an object.

A  query , on the other hand, is a method that returns information about the state of an object, but must not influence this state or have any other side effects.

According to CQS, you should be able to classify each method of an object in exactly one of the categories. Methods that change the state and have side-effects, and at the same time return information about the state, should therefore be avoided.

At first glance, meeting the requirement seems trivial. Considering classic  get  and  set  methods, it is clear that some are queries and others are commands. However, the practice knows more advanced methods that can no longer be assigned so easily.

For example, a method that saves a file and at the same time returns the number of bytes written would be questionable. Saving the file is a side effect, so it is a command. However, since it also returns the number of bytes written, this is also a query. How can this case be dealt with if the CQS principle is to be observed?

An interesting approach is suggested by Yegor Bugayenko in his book  Elegant Objects : Instead of creating the method as outlined above, you should reduce it to a query that returns a dedicated object representing a one-time save:

This new object then has the actual method  save , which is now a command, and the method  getBytesWritten  as query. In this way, the duality of the original method can be resolved into two separate methods as a command and query.

The reason why the procedure works in the described way is the separation of writing and reading, even in a process that supposedly does both at the same time.

Separating writing and reading

The  CQRS  design pattern raises the idea of separating writing and reading data from object to system level. This means, for example, that an application has not only one but two APIs to address it: While one API is used for writing data, the other is used for reading.

The separation does not necessarily have to be technical, but at least it should be thoughtfully planned. At first glance, this seems absurd and looks like unnecessary effort. In fact, however, the approach does offer some serious advantages.

A typical problem for applications that are subject to a high load is, for example, normalizing the database. For writing, a strictly normalized database is advantageous because writing operations can be carried out quickly and consistency guaranteed. At the same time, however, this brings with it massive reading problems, because a highly normalized database cannot be read out easily. Instead, it usually requires the use of numerous  JOIN  statements, which slow down reading dramatically.

On the other hand, if the database is optimized for the most efficient reading, a completely denormalized system should be aimed for. In this case, a single  SELECT  statement is sufficient for each read access, but writing becomes extremely time-consuming. The scenario also makes it extremely difficult and error-prone to guarantee consistency.

If, on the other hand, CQRS is used and the two aspects are separated on an architectural level, the problems go away. Then it is possible to work with two databases, one of which is normalized and responsible for writing, the other one denormalized and responsible for reading. This way, both writing and reading processes can be done optimally and with the best possible performance.

Thesis 1: CQRS is suitable for systems in which the number of writing and reading accesses differs greatly.

In addition, the separate scaling of an application’s read/write side enables the application to be scaled in a way that it can be optimally adapted to the load of the respective situation as required.

Thesis 2: CQRS is suitable for systems whose read and write sides should be scaled individually.

Eventual consistent

However, this procedure means that the two databases must be synchronized. This in turn raises the question of the guarantees under which this is done. In particular, if the separation of writing and reading actually takes place with the help of physically different databases, it becomes clear that distributed transactions are probably not a very suitable means.

Therefore, in CQRS-based systems, the guaranteed consistency between the read and write sides is often given up in favor of availability: In case of doubt, it is better to get a response from the system, even if it may be slightly outdated, than none at all.

Of course, this does not apply to all scenarios. It is obvious that the approach is not appropriate, for example, for systems that affect people’s lives or health: guaranteed consistency is probably desirable in the case of an eye laser, surgical intervention or the control of a nuclear power plant.

However, many other cases do well with a soft consistency. Real life also works in many places with this so-called  eventual consisteny , i.e. an  occasional consistency : Whoever orders a drink in a café usually receives the goods before they have to be paid for. This means that there is no transaction, which is why consistency from the café’s point of view is not guaranteed in the meantime.

Thesis 3: CQRS is suitable for systems where availability is more important than consistency and eventual consistency is not an exclusion criterion.

Asynchronous UIs

Considering the approach to be complete, this means that commands sent to the application do not return anything – completely in accordance with the CQS principle, which stipulates that commands change the state and have side-effects, but that they cannot return information about the internal state. But what do you do with the results of the commands that do necessarily exist?

Of course, the user interface can use a query to check regularly whether a result exists, but such a  pull -based procedure is cumbersome and time-consuming. It would be better to have a  push  notification, which will be delivered automatically as soon as a command is processed. Exactly this is solved with the help of so-called  events , which represent a reaction to a command.

Thesis 4: CQRS is suitable for systems that work with commands and (asynchronous) events to map the interaction with the user.

For the user interface, this means that a command is first sent away in a  fire-and-forget  style and then the UI waits for the associated event. It is questionable whether or not you want to prevent the user from performing other tasks during this time. If you allow the user to wait, this results in a consistent state of the UI, but his nerves are often unnecessarily strained.

Therefore, assuming that most of the commands are processed successfully anyway, you can let the UI work asynchronously: As soon as a command is delivered to the backend, only the receipt is acknowledged. The user can then continue working and even navigate to other parts of the application if necessary. The result of the command is then displayed asynchronously at a later time, if this is still relevant. This is often only relevant in the event of an error.

Thesis 5: CQRS is suitable for systems whose graphical user interface can or should work asynchronously.

Another option to quickly give feedback to the user is to falsify the application’s response in the graphical user interface, i.e. display the probable response directly. This is the way most online shops work, for example, which initially confirm receipt of the order and claim that it is now being processed and delivered. In fact, processing often only starts at a later point in time, which the customer only learns in the event of an error, for example, if the desired article is no longer in stock.

Collecting events

Although events are not the original concept of CQRS, they are an excellent counterpart to commands. Therefore, it is advisable to collect these events in a database and use them as a starting point for changing the status. The principle is called  event sourcing .

Thesis 6: CQRS is suitable for systems with a persistence layer based on event sourcing.

This does not store the current state of the application, but the individual events that have led to the current state. The current status can then be restored at any later point in time via a  replay . A database that stores such events and is optimized for the execution of replays is called  event store .

The read database can also be filled from these events by semantically interpreting the individual events and mapping them to classic CRUD statements. Since the events contain domain semantics, they can be interpreted differently as required, so that different read tables can be generated from the same raw data.

Since the events do not describe the current status, but the way to get there, this can be done afterwards, for example, to answer questions that have arisen only in the course of time: Provided that the semantics contained in the events permit the corresponding evaluation, this is possible without any problems.

In addition, CQRS can also be perfectly combined with  DDD  (domain-driven design) as the command- and event-oriented approach fits in well with the concept that puts domain-oriented events at the forefront of software modeling. Of course, CQRS can also be used without event sourcing or DDD, just as these concepts work without CQRS. However, there is no denying that the three concepts complement each other very well.

Thesis 7: CQRS is suitable for systems that use DDD to model the underlying domain.

What about CRUD?

Occasionally, CQRS is also mentioned in connection with CRUD, but usually not as a suitable supplement, but as a contrast. Theoretically, the two approaches do not exclude each other, but in practice there is hardly any benefit from their combination: Since CQRS requires the separation of writing and reading, one acts with two databases or at least with two database schemas, which have to be synchronized as already mentioned.

This is extremely difficult with pure CRUD, as  with CRUD there is no semantics for updating the read side . As described above, these can be obtained via domain events, which can then be used both as feedback to the user interface and as data for the event store.

Nevertheless, there are numerous applications where pure CRUD is completely legitimate. This is the case, for example, if an application ultimately only does  forms over data , i.e. does not contain any complex domain logic, but merely provides masks with which the raw data from the database can be edited.

Thesis 8: CQRS is suitable for systems whose domain logic is too complex for pure CRUD.

CQRS is an exciting architectural approach that demands an unusual handling of data. The separation of writing and reading might be familiar to the fewest developers, but makes sense in terms of scalability, modern asynchronous user interfaces, and the proximity to event sourcing and DDD.

Nevertheless, CQRS is not the magic silver bullet that solves all problems. CQRS is particularly  not  suitable for small applications that do not require a high degree of scalability and that do not have complex domain logic, and for applications that have a direct impact on life or health, CQRS is not or only to a very limited extent suitable. Other approaches may be preferable here.

However, CQRS is ideal for most web and cloud applications: here, scalability is often an essential requirement for the software. In addition, much more is usually read than written, which speaks for the individual scalability of both sides. If you add event sourcing and DDD to CQRS, you have an excellent basis for the development of modern web and cloud applications.

This article is written by Golo Roden. The author’s bio: “Founder and CTO of the native web. Prefers JS & Node.js Node.js is an asynchronous event-driven JavaScript runtime and is the most effective when building scalable network applications. Node.js is free of locks, so there's no chance to dead-lock any process. , and has written the first German book on this topic, “Node. js & co.”. He works for various IT magazines, and manages several conferences.”

Share this post

Development & consulting.

Trainings & Education

Why learn from us?

Online Training & Mentorship for Software Developers

Designing Microservices Architectures

Handling Microservices with Kubernetes

Modern Front-End with React

Building Complex Apps with Angular

Node.js Fundamentals

RESOURCES & COMMUNITY

RisingStack blog

Free eBooks

Microservices Weekly

Weekly Node Updates

Node.js Meetups by RisingStack

Open Positions

Full-Stack JS Certificate

RisingStack in the JS Community

Privacy Policy

© RisingStack, Inc.  2022 | RisingStack® and Trace by RisingStack® are registered trademarks of RisingStack, Inc.

Compartilhar

CQRS_Journey_Guide

Carludo Testoso

Antes de você sair do material, preparamos uma oferta para você:

Esse e outros conteúdos desbloqueados

Materiais de diversas disciplinas

Impressão de materiais

Agora você pode testar o

Passei direto grátis.

E aí, curtiu este material?

Ajude a incentivar outros estudantes a melhorar o conteúdo

Gostou desse material? Compartilhe! 🧡

Informática I

42.528 Materiais compartilhados

Baixe o app para aproveitar ainda mais

Leia os materiais offline, sem usar a internet. Além de vários outros recursos!

Prévia do material em texto

Perguntas relacionadas

Passo a passo para o uso da formatação condicional passo 1: clicar na célula, ou conjunto de células, onde você deseja que ocorra a formatação cond....

Praticando Para Aprender

Questão 1 - Responda: 1.1. [1,0 ponto] O que é Criptografia? R.: Criptografia é o estudo dos princípios e das técnicas pelas quais a informação p...

Questões para o Sucesso

Questão 2 - Cada folha de uma planilha é uma grade formada por linhas e colunas que ao se encontrarem definem células. Por exemplo, a linha 2 e a c...

Questão 3 - [2,0 pontos] atualmente tem aparecido uma nova forma de vírus, que é classificada como malware; a contaminação se dá pelo mau uso da in..., perguntas recentes, uma das matérias estudadas nesta disciplina foi a planilha eletrônica.  sendo assim, descreva um cenário onde uma planilha poderia ser utilizada pa....

fe.alves242811

O que é a plataforma "Microsoft Office" ? O Microsoft Office é um pacote com diversos aplicativos para usos diversos. O Word é um processador de t...

Desafios Para o Conhecimento

Uma palavra de um documento texto foi selecionada em sua versão em português e configuração padrão. Supondo que essa palavra se encontrava em seu e...

Ao inicializar o programa libreoffice impress, aparece uma caixa de diálogo que permite a escolha de um modelo para a apresentação. o modelo é util..., no libreoffice writer, há diversas possibilidades para formatação do texto. a imagem a seguir mostra algumas delas. selecione a alternativa que rel..., o libreoffice impress é usado para a criação e apresentação de slides. podemos comparar o impress com qual software do microsoft office o libreof..., o que é o microsoft power point o microsoft powerpoint é um programa utilizado para criação/edição e exibição de apresentações gráficas. o micro..., qual das funções abaixo substitui a fórmula "= b1+b2+b3+b4+b5+b6+b7+b8+b9+b10" a função =soma(b1:b10) substitui a fórmula "= b1+b2+b3+b4+b5+b6+b..., quais são os dois operadores de referência utilizados nas funções das planilhas eletrônicas dois pontos (:) é um operador de referência utilizado..., uma pessoa mal intencionada tenta obter informações como números de cartões de crédito, senhas, dados de contas ou outras informações pessoais conv....

You are using an outdated browser. Please upgrade your browser to improve your experience.

• Restaurants
• Best-of Guides
• MICHELIN Guide Ceremony
• My Favorites
• Subscribe to newsletter
• Booking partnership with OpenTable
• Booking partnership with Resy
• Juan Fernando Cortés is the MICHELIN Guide Atlanta 2023 Sommelier Award Winner

The Chastain's sommelier take us on his journey with wine.

MICHELIN Guide Ceremony Sommelier Award Editor's Pick Atlanta

Congratulations to Juan Fernando Cortés of The Chastain , the MICHELIN Guide Atlanta 2023 Sommelier of the Year Award Winner, sponsored by Wine Access!

We discover Cortés' first experience with wine—it was when he was 5 and sipped his father's vintage—and how those early moments seeing the grapes stomped shaped his relationship with the grape. We also find out how Cortés learned from sommeliers how to think differently in relation to wine and what he's currently craving.

Below, the Colombia native shares his favorite wines, ideal meal pairings, and everything in between. Cheers!

How were you introduced to the world of wine?

My father made his own wine, so I started drinking at the age of 5 with dinner. I’m from Cali, Colombia so it wasn’t as frowned upon. It was awesome! He would stomp the grapes with his feet, place them in a barrel, and let it ferment. Then we would drink straight from the barrel’s tap.

How has your relationship with wine changed?

Since then, quite a bit. Earlier in my career, I was impressed by people, winemakers and sommeliers. People that were doing things new and different, breaking from tradition in a way. At this point in my career, however, I find myself being more impressed with people and wines that can remain true to tradition. Elevating them, but not necessarily re-inventing the wheel.

What are you drinking these days?

I drink Côtes du Rhône pretty much exclusively right now. Ask me again in a few months.

Favorite non-alcoholic drink?

Matcha lemonade. The Chastain makes them very craveable.

What’s your ideal meal and pairing?

I’m a sucker for a great Rioja and a delicious rack of lamb.

What’s the biggest misconception about being a sommelier, or wine in general?

That all sommeliers have good palates. Wine is always changing, so you can never know everything. A lot of guests we encounter in this industry expect me (or us) to know everything. I love that I’m always learning something new.

What’s your criteria for adding a new wine to your list?

If it falls in the center of a Venn diagram in my head for being delicious, interesting, and sellable, it gets added. 

Favorite wine-related film, book, magazine, etc?

This show called 3 Sheets. You can still find it on YouTube I think.

Hero image: Laura Charon/The Chastain

Thumbnail: Courtesy of The Chastain

2023 Washington, D.C. MICHELIN Bib Gourmands

Two delicious and wallet-friendly Bib Gourmands join the selection.

2023 New York MICHELIN Bib Gourmands

The Big Apple benefits from more tasty and wallet-friendly fare with 11 new Bib Gourmands.

2023 Chicago MICHELIN Bib Gourmands

Five new Bib Gourmands from American to Mediterranean causing a stir in the Windy City.

Inside the Atlanta MICHELIN Guide Ceremony

Georgia's first MICHELIN Guide Ceremony was filled with emotion and flavor.

Keep Exploring - Stories we think you will enjoy reading

Want to Score a Table at Torrisi? Here's How To Do It Without Being Taylor Swift

Hear from one of New York’s hottest spots on how to snag a seat.

How COTE's Executive Chef Finds Balance for a Good Cause

David Shim on training for the New York City Marathon and how he powers through the stress of service.

Chef Charlie Mitchell of Clover Hill One Year After His Star Moment

The force behind the Brooklyn-based One MICHELIN Star chats about growth, challenges, and what he's learned.

Inside Wangbi, A Refined and Authentic Chef's Counter Experience in Koreatown

The elevated experience is located within a Bib Gourmand in K-Town.

Inside Amangiri, One of America's Most Exceptional Hotels

Four days and three nights at the exclusive Utah resort.

Inside Mujō—MICHELIN Star Sushi with a Southern Spin

A distinctly ‘Atlanta’ Japanese Edomae experience.

From Bytes To Biscuits

Chef/owner Erika Council of Bomb Biscuit Co. on waking up at 4:00 a.m. to make biscuits.

Bacchanalia Celebrates a Milestone in the Big Peach

Three decades of fine dining, Atlanta style.

Twisted Soul Cookhouse & Pours Brings the Flavor in Atlanta’s Blandtown

Southern traditions with a global twist bring oodles of flavor.

MICHELIN Guide

Use the app to find the best restaurants and hotels everywhere

Be the first to get news and update about the michelin guide.

MICHELIN Guide selections

The michelin group.

• Terms of Use
• Privacy Policy
• Legal Notice

Choose your Selection

• Global - English
• Orlando, Miami, Tampa
• Washington DC
• China Mainland
• Hong Kong - 繁體中文 | English
• Japan - 日本語 | English
• Macau - 繁體中文 | English
• Seoul - 한국어 | English
• Singapore - English | 简体中文
• Taiwan - 繁體中文 | English
• Thailand - ภาษาไทย | English
• Belgium - Français | Dutch
• Czech Republic
• Netherlands
• Republic of Ireland
• Switzerland - Français | Deutsch | Italiano
• Türkiye - Türkçe | English
• United Kingdom

Middle East

• Abu Dhabi - اَلْعَرَبِيَّةُ | English
• Dubai - اَلْعَرَبِيَّةُ | English