Design the Architecture — CQRS, Event Sourcing, Eventual Consistency, Materialized View

 We are going to Design our e-commerce Architecture with applying CQRS Pattern.

Now We can Design our Ordering microservices databases

I am going to split 2 databases for Ordering microservices
1 for the write database for relational concerns
2 for the read database for querying concerns

So when user create or update an order, I am going to use relational write database, and when user query order or order history, I am going to use no-sql read database. and make consistent them when syncing 2 databases with using message broker system with applying publish/subscribe pattern.

Now we can consider tech stack of these databases,

I am going to use SQL Server for relational writing database, and using Cassandra for no-sql read database. Of course we will use Kafka for syncing these 2 database with pub/sub Kafka topic exchanges.

So we should evolve our architecture with applying other Microservices Data Patterns in order to accommodate business adaptations faster time-to-market and handle larger requests.

How to Sync Databases with CQRS ?

 But when we separate read and write databases in 2 different database, the main consideration is sync these two database in a proper way.

So we should sync these 2 databases and keep sync always.

This can be solve by using Event-Driven Architecture. According to Event Driven Architecture, when something update in write database, it will publish an update event with using message broker systems and this will consume by the read database and sync data according to latest changes.

But this solution creates a consistency issue, because since we have implemented async communication with message brokers, the data would not be reflected immediately.

Press enter or click to view image in full size

This will operates the principle of “eventual consistency”. The read database eventually synchronizes with the write database, and it can be take some time to update read database in the async process. We discuss eventual consistency in the next sections.

So if we come back to our read and write databases in CQRS pattern, When starting your design, you can take read database from replicas of write database. By this way we can use different read-only replicas with applying Materialized view pattern can significantly increase query performance.

Also when we separated read and write databases, it means we can scale them independently. That means if our application is read-incentive, I mean if it much more query that write, than we can scale only reading databases very fast.

CQRS comes with separating commands and query databases. So this required to sync both 2 databases with offering event-driven architectures. And with Event-driven architectures there are some new patterns and practices should be consider when applying CQRS.

Event Sourcing pattern is the first pattern we should consider to use with CQRS. Mostly CQRS is using with “Event Sourcing pattern” in Event-Driven Architectures. So after we have learned the CQRS we should learn “Event Sourcing pattern”, because CQRS and “Event Sourcing pattern” is the best practice to use both of them.

Design the Architecture — CQRS, Event Sourcing, Eventual Consistency, Materialized View

CQRS Design Pattern in Microservices Architectures

 In this article, we are going to talk about Design Patterns of Microservices architecture which is The CQRS Design Pattern. As you know that we learned practices and patterns and add them into our design toolbox. And we will use these pattern and practices when designing e-commerce microservice architecture.

Press enter or click to view image in full size

By the end of the article, you will learn where and when to apply CQRS Design Pattern into Microservices Architecture with designing e-commerce application system.

CQRS Design Pattern

CQRS is one of the important pattern when querying between microservices. We can use CQRS design pattern in order to avoid complex queries to get rid of inefficient joins. CQRS stands for Command and Query Responsibility Segregation. Basically this pattern separates read and update operations for a database.

Normally, in monolithic applications, most of time we have 1 database and this database should respond both query and update operations. That means a database is both working for complex join queries, and also perform CRUD operations. But if the application goes more complex this query and crud operations will be also is going to be un-manageable situation.

In example of reading database, if your application required some query that needs to join more than 10 table, this will lock the database due to latency of query computation. Also if we give example of writing database, when performing crud operations we would need to make complex validations and process long business logics, so this will cause to lock database operations.

Press enter or click to view image in full size

So reading and writing database has different approaches that we can define different strategy to handle that operation. In order to that CQRS offers to use “separation of concerns” principles and separate reading database and the writing database with 2 database. By this way we can even use different database for reading and writing database types like using no-sql for reading and using relational database for crud operations.

Another consideration is we should understand our application use case behaviors, if our application is mostly reading use cases and not writing so much, we can say our application is read-incentive application. So we should design our architecture as per our reading requirements with focusing reading databases.

So we can say that CQRS separates reads and writes into different databases, Commands performs update data, Queries performs read data.

Commands should be actions with task-based operations like “add item into shopping cart” or “checkout order”. So commands can be handle with message broker systems that provide to process commands in async way.

Queries is never modify the database. Queries always return the JSON data with DTO objects. By this way, we can isolate the Commands and Queries.

In order isolate Commands and Queries, its best practices to separate read and write database with 2 database physically. By this way, if our application is read-intensive that means reading more than writing, we can define custom data schema to optimized for queries.

Materialized view pattern is good example to implement reading databases. Because by this way we can avoid complex joins and mappings with pre defined fine-grained data for query operations.

By this isolation, we can even use different database for reading and writing database types like using no-sql document database for reading and using relational database for crud operations.

How to Sync Databases with CQRS ? 

How to connect an Excel file from OneDrive in Power BI

 1^st open power BI desktop in your system == Select Blank Report

Righ click that excel > Go TO Info . Copy path

After removed extra think from url we will use the same url to access the excel. 

Select Home Tab > Get data >  Web

Paste url and click ok

If Everything is ok you can below screen.

Select the sheet you want and click the Load button

After successfully the data is view as per below window

Select the data you want. When you choose the fields, they are automatically populated on the screen.

In my case i am user empty file so NO data but if you reached till here you successfully connected with you data happy learning  

Angular 20 Upgrade Guide: Features, Use Cases & Best Practices

👋 Hello everyone,

Today, I’ll be highlighting the new features and improvements in Angular 20, a powerful web framework that empowers developers to build fast, scalable, and reliable applications.

---

🔧 Upgrade Steps for Angular 20

To upgrade your project:

1. Install the latest CLI:
   npm install -g @angular/cli

2. Update Angular core and CLI:
   ng update @angular/core@20 @angular/cli@20

3. Upgrade TypeScript to version 5.x

---

✨ Key Features in Angular 20

✅ Stable Signals API

• Signals are now officially stable.
• They help manage local component state without relying on RxJS for every change.

🧮 Computed Signals

• Read-only signals derived from other signals.
• Defined using the computed() function.
• Dynamically track dependencies.

⚡ Effects

• Run at least once and re-run when dependent signals change.
• Execute asynchronously during change detection.
• Track dependencies dynamically.

Use Cases for Effects:

• Logging data changes (analytics/debugging)
• Syncing with window.localStorage
• Custom DOM behavior
• Rendering with <canvas>, charts, or third-party libraries

---

🚀 Zoneless Change Detection

• Removes the need for Zone.js
• Improves performance and reduces unnecessary re-renders
• Speeds up rendering by up to 30%

---

🧩 Dynamic Component Creation with createComponent()

🔄 Why Use It?

To build flexible, modular UIs that respond to user interactions or app state without full page reloads.

💡 Key Benefits

• Dynamic UI Elements: Load modals, dialogs, charts, or widgets only when needed.
• Component Reusability: Reuse components with different data across contexts.
• Lazy Loading: Load components on demand to improve initial load performance.
• Customizable Views: Pass data at runtime for context-aware components.
• Flexible Layouts: Insert components dynamically based on user actions or system data.
• Reducing Complexity: Move logic to TypeScript, keeping templates clean and simple.

📌 Example Scenarios

• Modals and Popups: Show modal on user action without template clutter.
• Dynamic Forms: Build forms based on user roles or config files.
• Error Handling: Inject error notification components on failed API calls.
• Dashboard Widgets: Add charts/tables dynamically based on user configuration.

🛠️ Improvements in Angular 20

• Stabilized API for dynamic component creation
• Declarative, type-safe, and modern approach
• No need for ViewContainerRef or ComponentFactoryResolver
• Automatic handling of DI, lifecycle hooks, and content projection
• Works seamlessly with standalone components and signals

---

📦 Resource API in Angular 20

🌐 What Is It?

A new API for managing external resources like REST APIs, WebSockets, and static assets.

✅ Why Use It?

• Declarative Resource Management: Cleaner, reusable logic
• Centralized Error Handling: Simplifies network error management
• Caching & State Management: Tracks fetch status and caches responses
• Improved Performance: Supports retries and parallel fetching
• Ease of Integration: Works with Angular’s HttpClient

🧩 Benefits

• Simplified HTTP requests with @Resource decorator
• Declarative syntax for API calls
• Centralized error handling
• Built-in caching support

---

🧠 Extended Template Expression Syntax

🆕 New Syntax Features

• Optional Chaining (?.): Safely access nested properties
• Nullish Coalescing (??): Provide fallback values
• Robust Error Handling: Templates don’t break on missing data

Examples:

Interactivity on code previews is coming soon

{{ user().address?.city }}

{{ user().name ?? 'Name not provided' }}

---

🗺️ Standalone Routing Improvements

🛠️ What’s New?

• No need for NgModule imports
• Cleaner code structure
• Full support for lazy loading and guards
• Uses inject() for DI instead of constructor injection
• Fully typed and declarative routing

---

✅ Best Practices in Angular 20

🧾 TypeScript

• Use strict type checking
• Prefer type inference
• Avoid any; use unknown when uncertain

🅰️ Angular

• Prefer standalone components
• Avoid @HostBinding and @HostListener; use host object
• Use NgOptimizedImage for static images

🧱 Components

• Keep components small and focused
• Use input()/output() functions
• Use computed() for derived state
• Set ChangeDetectionStrategy.OnPush
• Prefer inline templates for small components
• Use reactive forms
• Avoid ngClass and ngStyle; use class and style bindings

📊 State Management

• Use signals for local state
• Use computed() for derived state
• Keep transformations pure
• Use update() or set() instead of mutate()

🧩 Templates

• Keep templates simple
• Use native control flow (@if, @for, @switch)
• Use async pipe for observables

🧰 Services

• Design around single responsibility
• Use providedIn: 'root' for singletons
• Prefer inject() over constructor injection