Hello Stackers, Event-carried state transfer is to make the message event sent by the service contain a full message. In our case, it means that the event content sent by the order service contains all order data plus order details, such as ordered goods, shipping address, billing address, and the identity of the customer who placed the order.
With event-carried state transfer, there is no need for an API call to the service that sends data, so the problem of bombarding API calls from services that require data does not occur again. Likewise, there are no more services that depend on other services.
Advantages of Using Event-Carried State Transfer
As explained above, by using event-carried state transfer, we get several advantages, including:
- No dependence: each service will not depend on the other service anymore. No more waiting for each other between teams during development; no more problematic service because of other service problems.
- High Availability: Because each service now stands alone without dependence on other services, if there is a service that has a problem or is dead, other services will not be problematic or dead.
- Decrease traffic to the sender of the event message because there is no need for an API call to the service that sends the event message.
- Lowers response time because there is no need to make API calls to other services, thus making the response service time better.
Disadvantages of Using Event-Carried State Transfer
There are advantages, but there must also be disadvantages when we use event-carried state transfer or even event-driven architecture in general, including:
- Data duplication, because the sender’s service data is duplicated in the receiving service, causes the storage medium to be larger.
- Eventual consistent. Event-Driven is sometimes not as real-time using API-Call; there will be a possibility of delay when the service sends and receives data, so the possibility of inconsistent data can occur, although it may only be a matter of seconds.
- Splattered business flow In our case, if we use API-driven to view business flows, we only need to see them in order of service. However, when using event-driven, we can’t see the business flow clearly anymore because all business flows have been distributed across all services. It will be difficult for a new team member to see the business channel in the big picture.
Okay, That’s All folks, see you in the next episode.
