Saga Design Pattern అంటే ఏమిటి? – E-Commerce Application తో పూర్తి వివరణ
Microservices Architecture లో ఒక business operation ఒకే database లో కాకుండా, అనేక microservices మరియు databases లో జరుగుతుంది.
ఉదాహరణకు E-Commerce application లో ఒక customer order place చేసినప్పుడు:
Customer
↓
Order Service
↓
Inventory Service
↓
Payment Service
↓
Shipping Service
↓
Order Completed
ఇక్కడ ప్రతి service కి తనదైన database ఉంటుంది.
Order Service → Order DB
Inventory Service → Inventory DB
Payment Service → Payment DB
Shipping Service → Shipping DB
ఇలాంటి distributed transactions ను manage చేయడానికి ఉపయోగించే ముఖ్యమైన design pattern Saga Design Pattern.
1. Saga Design Pattern అంటే ఏమిటి?
Saga Pattern అనేది distributed transaction ను చిన్న చిన్న local transactions గా విభజించి, వాటిని sequential గా execute చేసే pattern.
ఒక transaction fail అయితే, ఇప్పటికే విజయవంతంగా పూర్తయిన transactions కు Compensating Transactions execute చేసి system ను సరైన business state కి తీసుకువస్తుంది.
సింపుల్గా:
Transaction 1
↓
Transaction 2
↓
Transaction 3
↓
Transaction 4
Transaction 3 fail అయితే:
Transaction 1 ✓
Transaction 2 ✓
Transaction 3 ✗
↓
Compensation 2
↓
Compensation 1
2. Saga ఎందుకు అవసరం?
సాధారణ monolithic application లో:
BEGIN TRANSACTION
Create Order
Reserve Inventory
Process Payment
Create Shipment
COMMIT
అన్ని operations ఒకే database transaction లో ఉండవచ్చు.
ఏదైనా fail అయితే:
ROLLBACK
చేయవచ్చు.
కానీ Microservices లో:
Order Service → OrderDB
Inventory Service → InventoryDB
Payment Service → PaymentDB
Shipping Service → ShippingDB
ఇవి వేర్వేరు databases.
కాబట్టి ఒక single SQL transaction తో అన్ని databases ను rollback చేయడం సాధారణంగా సరైన approach కాదు.
అందుకే Saga ఉపయోగిస్తాము.
3. E-Commerce Real-Time Example
ఒక customer ₹80,000 విలువైన laptop order చేశాడని అనుకుందాం.
Business flow:
1. Order Create
↓
2. Inventory Reserve
↓
3. Payment Process
↓
4. Shipment Create
↓
5. Order Confirm
ప్రతి step ఒక local transaction.
4. ప్రతి Transaction ఎలా జరుగుతుంది?
Transaction 1 – Order Creation
Order Service:
Order Status = Pending
Database:
OrderId = 1001
CustomerId = C001
Amount = ₹80,000
Status = Pending
Order successfully create అయిన తర్వాత:
OrderCreated
event publish చేస్తాము.
5. Transaction 2 – Inventory Reservation
Inventory Service:
Available Stock = 100
Customer order చేసిన తర్వాత:
Available Stock = 99
Reserved Stock = 1
అంటే inventory reserve అయింది.
తర్వాత:
InventoryReserved
event publish అవుతుంది.
6. Transaction 3 – Payment
Payment Service:
Order Amount = ₹80,000
Payment successfully complete అయితే:
Payment Status = Completed
తర్వాత:
PaymentCompleted
event publish చేస్తుంది.
7. Transaction 4 – Shipping
Shipping Service:
Shipment Created
తర్వాత:
ShipmentCreated
event publish చేస్తుంది.
Saga అన్ని steps complete అయిన తర్వాత:
Order Status = Confirmed
అవుతుంది.
8. Complete Successful Flow
Customer
|
↓
Order Service
|
| OrderCreated
↓
Saga Orchestrator
|
| ReserveInventory
↓
Inventory Service
|
| InventoryReserved
↓
Saga Orchestrator
|
| ProcessPayment
↓
Payment Service
|
| PaymentCompleted
↓
Saga Orchestrator
|
| CreateShipment
↓
Shipping Service
|
| ShipmentCreated
↓
Saga Orchestrator
|
↓
Order Confirmed
9. ఒక Transaction Fail అయితే ఏమవుతుంది?
ఇది Saga Pattern లో చాలా ముఖ్యమైన విషయం.
ఉదాహరణకు:
Order Creation ✓
Inventory Reservation ✓
Payment ✗
Payment fail అయింది.
ఇప్పుడు Inventory ఇప్పటికే reserve అయింది.
Normal database rollback చేయలేము.
అందువల్ల:
Payment Failed
↓
Release Inventory
↓
Cancel Order
అంటే:
T1 Create Order ✓
T2 Reserve Inventory ✓
T3 Payment ✗
C2 Release Inventory ✓
C1 Cancel Order ✓
10. Compensation అంటే ఏమిటి?
Saga లో rollback బదులు Compensating Transaction ఉపయోగిస్తాము.
ఉదాహరణ:
| Forward Transaction | Compensating Transaction |
|---|---|
| Create Order | Cancel Order |
| Reserve Inventory | Release Inventory |
| Process Payment | Refund Payment |
| Create Shipment | Cancel Shipment |
| Apply Coupon | Restore Coupon |
| Add Loyalty Points | Remove/Restore Points |
అంటే:
Compensation అనేది database rollback కాదు. ఇప్పటికే జరిగిన business operation యొక్క ప్రభావాన్ని reverse చేసే కొత్త business transaction.
11. Payment Success అయి Shipping Fail అయితే?
ఇంకొక scenario చూద్దాం.
Order ✓
Inventory ✓
Payment ✓
Shipping ✗
ఇప్పుడు:
Shipping Failed
↓
Refund Payment
↓
Release Inventory
↓
Cancel Order
అంటే:
T1 Order Created ✓
T2 Inventory Reserved ✓
T3 Payment Completed ✓
T4 Shipping Failed ✗
C3 Refund Payment ✓
C2 Release Inventory ✓
C1 Cancel Order ✓
Final state:
Order = Cancelled
Inventory = Released
Payment = Refunded
Shipping = Failed
12. Saga లో రెండు రకాల Implementation
Saga Pattern ను ప్రధానంగా రెండు విధాలుగా implement చేయవచ్చు.
1. Choreography
Central coordinator ఉండదు.
Services events ద్వారా ఒకదానితో ఒకటి communicate చేస్తాయి.
Order Service
|
OrderCreated
↓
Inventory Service
|
InventoryReserved
↓
Payment Service
|
PaymentCompleted
↓
Shipping Service
ఇక్కడ ప్రతి service తన next action ను event ఆధారంగా నిర్ణయిస్తుంది.
13. Choreography యొక్క సమస్య
చిన్న application లో ఇది బాగుంటుంది.
కానీ services పెరిగితే:
Order
Inventory
Payment
Shipping
Notification
Coupon
Loyalty
Fraud
Tax
చాలా event dependencies ఏర్పడవచ్చు.
అప్పుడు flow అర్థం చేసుకోవడం కష్టమవుతుంది.
14. Orchestration
ఇక్కడ ఒక central Saga Orchestrator ఉంటుంది.
Saga Orchestrator
|
+-------------+-------------+
| | |
↓ ↓ ↓
Order Inventory Payment
Service Service Service
|
↓
Shipping
Orchestrator ఇలా చెబుతుంది:
Reserve Inventory
↓
Process Payment
↓
Create Shipment
ఏదైనా fail అయితే:
Release Inventory
↓
Refund Payment
↓
Cancel Order
Complex enterprise applications లో Saga Orchestration చాలా useful.
15. Data Models ఎలా Design చేయాలి?
Saga design లో data models చాలా ముఖ్యమైనవి.
ప్రతి microservice తన data కు owner గా ఉండాలి.
Order Model
public class Order
{
public Guid Id { get; set; }
public Guid CustomerId { get; set; }
public decimal TotalAmount { get; set; }
public OrderStatus Status { get; set; }
public DateTime CreatedAt { get; set; }
}
Order Status:
public enum OrderStatus
{
Pending,
InventoryReserved,
PaymentProcessing,
Confirmed,
Failed,
Cancelled
}
16. Order Item Model
public class OrderItem
{
public Guid Id { get; set; }
public Guid OrderId { get; set; }
public Guid ProductId { get; set; }
public int Quantity { get; set; }
public decimal Price { get; set; }
}
17. Inventory Model
public class Inventory
{
public Guid ProductId { get; set; }
public int AvailableQuantity { get; set; }
public int ReservedQuantity { get; set; }
}
ఉదాహరణ:
Product Available Reserved
Laptop 100 0
Reserve చేసిన తర్వాత:
Laptop 99 1
18. Inventory Reservation Model
Inventory reservation కోసం separate model ఉంచడం మంచిది.
public class InventoryReservation
{
public Guid Id { get; set; }
public Guid OrderId { get; set; }
public Guid ProductId { get; set; }
public int Quantity { get; set; }
public ReservationStatus Status { get; set; }
}
Status:
public enum ReservationStatus
{
Reserved,
Released
}
ఇది compensation సమయంలో చాలా ఉపయోగపడుతుంది.
19. Payment Model
public class Payment
{
public Guid Id { get; set; }
public Guid OrderId { get; set; }
public decimal Amount { get; set; }
public PaymentStatus Status { get; set; }
public string TransactionReference { get; set; }
}
Status:
public enum PaymentStatus
{
Pending,
Completed,
Failed,
Refunded
}
20. Shipping Model
public class Shipment
{
public Guid Id { get; set; }
public Guid OrderId { get; set; }
public string Address { get; set; }
public ShipmentStatus Status { get; set; }
}
21. Saga State Model
Saga orchestrator కూడా తన state ను persist చేయాలి.
public class OrderSaga
{
public Guid SagaId { get; set; }
public Guid OrderId { get; set; }
public SagaStatus Status { get; set; }
public bool OrderCreated { get; set; }
public bool InventoryReserved { get; set; }
public bool PaymentCompleted { get; set; }
public bool ShipmentCreated { get; set; }
public DateTime CreatedAt { get; set; }
public DateTime UpdatedAt { get; set; }
}
దీని వల్ల orchestrator కి:
- ఏ step complete అయింది?
- ఏ step fail అయింది?
- ఏ compensation చేయాలి?
- retry ఎక్కడి నుంచి చేయాలి?
అన్నీ తెలుస్తాయి.
22. Commands మరియు Events
Saga implementation లో Command మరియు Event మధ్య difference తెలుసుకోవడం చాలా ముఖ్యం.
Command
“ఇది చేయండి” అని చెబుతుంది.
CreateOrder
ReserveInventory
ProcessPayment
CreateShipment
RefundPayment
ReleaseInventory
CancelOrder
Event
“ఇది జరిగింది” అని తెలియజేస్తుంది.
OrderCreated
InventoryReserved
InventoryReservationFailed
PaymentCompleted
PaymentFailed
ShipmentCreated
ShipmentFailed
23. Example Command
public record ReserveInventoryCommand(
Guid MessageId,
Guid SagaId,
Guid OrderId,
Guid ProductId,
int Quantity);
24. Example Event
public record InventoryReservedEvent(
Guid MessageId,
Guid SagaId,
Guid OrderId);
Failure event:
public record InventoryReservationFailedEvent(
Guid MessageId,
Guid SagaId,
Guid OrderId,
string Reason);
25. Saga State Machine
Saga flow ను state machine లాగా design చేయవచ్చు.
OrderCreated
|
↓
InventoryPending
|
+----------------+
| |
Success Failure
| |
↓ ↓
PaymentPending Cancel Order
|
+---+---+
| |
Success Failure
| |
↓ ↓
Shipping Release Inventory
Pending |
| ↓
Success Cancel Order
|
↓
Completed
26. Saga Orchestrator – Basic Logic
Inventory reservation కోసం:
public async Task Handle(OrderCreatedEvent message)
{
await ReserveInventory(message);
}
Inventory success:
public async Task Handle(InventoryReservedEvent message)
{
await ProcessPayment(message);
}
Payment success:
public async Task Handle(PaymentCompletedEvent message)
{
await CreateShipment(message);
}
Shipping success:
public async Task Handle(ShipmentCreatedEvent message)
{
await ConfirmOrder(message);
}
Payment failure:
public async Task Handle(PaymentFailedEvent message)
{
await ReleaseInventory(message);
await CancelOrder(message);
}
ఇది basic concept మాత్రమే. Production implementation లో retries, idempotency, persistence, outbox మొదలైనవి తప్పనిసరిగా పరిగణించాలి.
27. Data Consistency ఎలా Maintain చేస్తాము?
Saga strong consistency ఇవ్వదు.
ఇది సాధారణంగా Eventual Consistency model పై పనిచేస్తుంది.
ఉదాహరణకు కొంత సమయం పాటు:
Order = Pending
Inventory = Reserved
Payment = Processing
ఉండవచ్చు.
Payment complete అయిన తర్వాత:
Order = Confirmed
Inventory = Reserved
Payment = Completed
లేదా Payment fail అయితే:
Order = Cancelled
Inventory = Released
Payment = Failed
అంటే system చివరకు valid business state కి చేరుతుంది.
28. Idempotency ఎందుకు అవసరం?
Distributed systems లో message ఒకటి కంటే ఎక్కువసార్లు రావచ్చు.
ఉదాహరణ:
ReserveInventory
message రెండుసార్లు వచ్చిందనుకుందాం.
Idempotency లేకపోతే:
Message 1 → Reserve 1
Message 2 → Reserve 1
Stock:
100 → 98
అవుతుంది.
కానీ మనకు కావాల్సింది:
100 → 99
కాబట్టి duplicate message వచ్చినా operation రెండుసార్లు execute కాకుండా చూడాలి.
29. Message ID
ప్రతి message కి unique ID ఇవ్వవచ్చు.
public class ProcessedMessage
{
public Guid MessageId { get; set; }
public DateTime ProcessedAt { get; set; }
}
Processing ముందు:
Message ఇప్పటికే process అయిందా?
అవును అయితే:
Ignore
కాకపోతే:
Process
Save MessageId
30. Transactional Outbox Pattern
Saga తో పాటు Transactional Outbox Pattern కూడా production systems లో చాలా ఉపయోగకరమైన pattern.
ఒక సమస్య చూద్దాం.
Order create చేశాం:
Database Insert ✓
తర్వాత event publish చేయాలి:
OrderCreated
కానీ application crash అయితే:
Database Insert ✓
Event Publish ✗
Order database లో ఉంది.
కానీ Saga కి OrderCreated event తెలియదు.
ఇది serious consistency problem.
31. Outbox ఎలా పనిచేస్తుంది?
Order Service database లో:
Orders
OutboxMessages
ఉంటాయి.
ఒకే local transaction లో:
BEGIN TRANSACTION
INSERT Order
INSERT OutboxMessage
COMMIT
అంటే రెండూ successfully save అవుతాయి.
Outbox table:
MessageId
Type
Payload
Published
CreatedAt
Background worker:
Outbox
↓
Read unpublished messages
↓
Publish to Message Broker
↓
Mark Published = true
32. Saga + Outbox Architecture
Production architecture:
Saga Orchestrator
|
↓
Azure Service Bus
|
+-----------------+----------------+
| | |
↓ ↓ ↓
Order Service Inventory Service Payment
| | |
Order DB Inventory DB Payment DB
| | |
Outbox Outbox Outbox
Shipping Service కూడా ఇదే pattern follow చేయవచ్చు.
33. Compensation కూడా Fail కావచ్చు
ఇది real-world systems లో చాలా important.
ఉదాహరణ:
Order ✓
Inventory ✓
Payment ✗
Saga:
ReleaseInventory
పంపింది.
కానీ Inventory Service కూడా fail అయింది.
ReleaseInventory ✗
ఇప్పుడు Saga state:
Order = Pending
Inventory = Reserved
Payment = Failed
ఇక్కడ Saga terminate కాకూడదు.
Retry చేయాలి.
ReleaseInventory
↓
Retry
↓
Retry
↓
Success
34. Retry + Exponential Backoff
ఉదాహరణ:
Attempt 1
↓
5 seconds
↓
Attempt 2
↓
30 seconds
↓
Attempt 3
↓
5 minutes
ఇది Exponential Backoff.
ఎన్ని retries చేయాలో business requirement ఆధారంగా నిర్ణయించాలి.
Retries తరువాత కూడా fail అయితే message ను:
Dead Letter Queue
కి పంపవచ్చు.
35. Timeout Handling
Payment Service response రాకపోతే:
Payment Request
↓
Waiting...
↓
Timeout
Timeout వచ్చిన వెంటనే blindly refund చేయడం లేదా మరో payment request పంపడం ప్రమాదకరం.
మొదట payment status check చేయాలి.
Payment Timeout
↓
Check Payment Status
↓
Success? → Continue
Failed? → Compensate
Unknown? → Retry / Reconcile
ఇది payment systems లో చాలా ముఖ్యమైన concept.
36. Concurrency Problem
Suppose:
Available Stock = 1
Customer A మరియు Customer B ఒకేసారి order చేస్తారు.
Customer A → Reserve
Customer B → Reserve
Concurrency control లేకపోతే ఇద్దరికీ stock reserve అయ్యే అవకాశం ఉంది.
SQL లో conditional update ఉపయోగించవచ్చు:
UPDATE Inventory
SET AvailableQuantity = AvailableQuantity - 1
WHERE ProductId = @ProductId
AND AvailableQuantity >= 1;
తర్వాత:
Rows Affected = 1
అయితే reservation success.
Rows Affected = 0
అయితే stock available లేదు.
37. Complete Failure Scenarios
Scenario 1 – Everything Successful
Order ✓
Inventory ✓
Payment ✓
Shipping ✓
Result:
Order = Confirmed
Saga = Completed
Scenario 2 – Inventory Failed
Order ✓
Inventory ✗
Compensation:
Cancel Order
Scenario 3 – Payment Failed
Order ✓
Inventory ✓
Payment ✗
Compensation:
Release Inventory
Cancel Order
Scenario 4 – Shipping Failed
Order ✓
Inventory ✓
Payment ✓
Shipping ✗
Compensation:
Refund Payment
Release Inventory
Cancel Order
Scenario 5 – Compensation Failed
Payment Failed
↓
Release Inventory
↓
Inventory Service Failed
Solution:
Retry
↓
Retry
↓
Dead Letter Queue
↓
Alert
↓
Manual Recovery
38. Azure + .NET లో Saga Architecture
మీరు Azure మరియు .NET ఉపయోగిస్తున్నట్లయితే ఒక production architecture ఇలా ఉండవచ్చు:
Client
|
↓
API Gateway
|
↓
Order Service
|
↓
Saga Orchestrator
|
Azure Service Bus
|
+-------------+-------------+
| | |
↓ ↓ ↓
Inventory Payment Shipping
Service Service Service
| | |
↓ ↓ ↓
Azure SQL Azure SQL Azure SQL
Supporting services:
Azure Key Vault
Application Insights
Azure Monitor
Azure Service Bus
Azure SQL
39. Azure Service Bus ఎందుకు ఉపయోగించవచ్చు?
Microservices మధ్య asynchronous communication కోసం:
Order Service
↓
Azure Service Bus
↓
Inventory Service
Messages reliable గా process చేయడానికి queues/topics ఉపయోగించవచ్చు.
ఉదాహరణ commands:
ReserveInventory
ProcessPayment
CreateShipment
ReleaseInventory
RefundPayment
CancelOrder
40. Production-Level Saga Architecture
ఒక enterprise-grade implementation ను ఇలా design చేయవచ్చు:
┌─────────────────────┐
│ API Gateway │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Order Service │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Saga Orchestrator │
└──────────┬──────────┘
↓
┌─────────────────────┐
│ Azure Service Bus │
└──────┬──────┬───────┘
│ │
┌─────────┘ └─────────┐
↓ ↓
Inventory Service Payment Service
│ │
Inventory DB Payment DB
│ │
Outbox Outbox
│ │
└──────────┬───────────────┘
↓
Shipping Service
│
Shipping DB
│
Outbox
41. Saga Implementation – Step-by-Step
ఒక real project లో నేను ఈ order లో implement చేస్తాను:
Step 1
Business transaction identify చేయాలి.
Place Order
Step 2
దాన్ని local transactions గా break చేయాలి.
Order
↓
Inventory
↓
Payment
↓
Shipping
Step 3
ప్రతి service కి separate database design చేయాలి.
Step 4
Commands మరియు Events define చేయాలి.
Step 5
Saga Orchestrator design చేయాలి.
Step 6
Saga state persist చేయాలి.
Step 7
ప్రతి service లో local database transaction implement చేయాలి.
Step 8
Transactional Outbox implement చేయాలి.
Step 9
Idempotent message consumers implement చేయాలి.
Step 10
Failure scenarios define చేయాలి.
Step 11
ప్రతి successful operation కి compensating transaction define చేయాలి.
Step 12
Retry మరియు timeout handling implement చేయాలి.
Step 13
Dead Letter Queue implement చేయాలి.
Step 14
Logging, tracing మరియు monitoring implement చేయాలి.
Step 15
End-to-end failure testing చేయాలి.
42. Saga లో Data Consistency ఎలా వస్తుంది?
Saga:
❌ Global ACID Transaction
కాదు.
బదులుగా:
Local ACID Transactions
+
Reliable Messaging
+
Compensation
+
Retry
+
Idempotency
+
Eventual Consistency
ద్వారా business consistency సాధిస్తుంది.
43. Saga Pattern యొక్క Advantages
✅ Microservices కు suitable
ప్రతి service independently deploy చేయవచ్చు.
✅ Distributed transactions కు solution
Multiple databases మధ్య business transaction manage చేయవచ్చు.
✅ Better scalability
Long-running database locks అవసరం ఉండదు.
✅ Failure recovery
Compensating transactions ద్వారా recover చేయవచ్చు.
✅ Asynchronous processing
Message brokers ఉపయోగించి services loosely coupled గా ఉండవచ్చు.
44. Saga Pattern Disadvantages
Saga కూడా ప్రతి సమస్యకు solution కాదు.
❌ Eventual consistency
Data అన్ని services లో వెంటనే consistent కాకపోవచ్చు.
❌ Complex failure handling
ప్రతి failure scenario కి compensation design చేయాలి.
❌ Debugging complexity
Distributed services వల్ల troubleshooting కష్టమవుతుంది.
❌ Duplicate messages
Idempotency అవసరం.
❌ Compensation failures
Compensation కూడా fail కావచ్చు.
❌ Complex workflows
చాలా ఎక్కువ services ఉంటే Saga state machine complex కావచ్చు.
45. Saga Pattern – Interview Answer
Interviewer:
“What is Saga Design Pattern?”
మీరు ఇలా చెప్పవచ్చు:
Saga Design Pattern అనేది microservices architecture లో distributed transactions ను manage చేయడానికి ఉపయోగించే pattern. ఒక పెద్ద business transaction ను multiple local transactions గా divide చేస్తాము. ప్రతి microservice తన database లో local transaction execute చేసి commit చేస్తుంది. ఏదైనా later transaction fail అయితే, ఇప్పటికే successful అయిన transactions కు compensating transactions execute చేసి system ను consistent business state కి తీసుకువస్తాము.
ఉదాహరణకు e-commerce order లో Order Creation → Inventory Reservation → Payment → Shipping అనే steps ఉంటాయి. Payment fail అయితే database-level rollback చేయకుండా Inventory Reservation కు Release Inventory అనే compensation మరియు Order కు Cancel Order అనే compensation execute చేస్తాము. Saga ను Choreography లేదా Orchestration ద్వారా implement చేయవచ్చు. Production systems లో Outbox, Idempotency, Retry, Timeout, Dead Letter Queue మరియు Distributed Tracing వంటి mechanisms కూడా ఉపయోగిస్తాము.
46. గుర్తుపెట్టుకోవాల్సిన ముఖ్యమైన Formula
SAGA
|
┌──────────┼──────────┐
↓ ↓ ↓
Local Events Compensation
Transaction
|
↓
Retry + Idempotency
|
↓
Eventual Consistency
ఒకే లైన్లో:
Saga = Local Transactions + Events + Compensation + Retry + Idempotency + Eventual Consistency
చివరి Takeaway
E-Commerce application లో:
Create Order
↓
Reserve Inventory
↓
Process Payment
↓
Create Shipment
↓
Confirm Order
అన్నీ successful అయితే:
Order = CONFIRMED
Payment fail అయితే:
Payment Failed
↓
Release Inventory
↓
Cancel Order
Shipping fail అయితే:
Shipping Failed
↓
Refund Payment
↓
Release Inventory
↓
Cancel Order
అందువల్ల Saga Design Pattern యొక్క main goal database rollback చేయడం కాదు; distributed business transaction fail అయినప్పుడు compensating actions ద్వారా system ను valid and consistent business state కి తీసుకురావడం.
