This is an English version of the article originally written in Japanese in 2022: https://zenn.dev/aircloset/articles/07ed9da7dd8d65

Hello everyone, good morning and good evening! I'm Tsuji, CTO of airCloset.

This article is the 25th day of airCloset's Advent Calendar 2022, so I hope you'll read the other articles as well!

As the title suggests, I'll be writing about the architecture that airCloset is aiming for in the future, so I'd be happy if you could read to the end.

Premise

While it may seem obvious, every architecture has its pros and cons, and the compatibility varies depending on the service content and the team members involved, so I believe there's no such thing as the ultimate architecture.

For reference, the article on Day 1 discusses airCloset's system configuration, so I hope you can understand what kind of architecture we're aiming for with this type of configuration.

Event-Driven Architecture

So, the architecture that airCloset is aiming for is "Event-Driven Architecture."

Do you all know about event-driven architecture? Let me first explain event-driven architecture itself.

Also, this article specifically deals with event-driven architecture in system-to-system integration, not application-level event-driven architecture using EventEmitter and the like.

What is Event-Driven Architecture?

Event-driven architecture, as the name suggests, is an architecture that realizes a system that receives events or messages and executes processes accordingly.

For example, thinking about the frontend is the easiest way to understand:

Receiving a Click event and executing data registration
Receiving a scroll event and showing/hiding elements

These are examples of integration using events, and incorporating this as the foundation of a system is event-driven architecture.

Difference Between API-Driven and Event-Driven

When you hear "receiving events and executing corresponding processes," you might think, "How is that different from API-driven?" Indeed, looking at just this aspect, they seem similar. The biggest difference between these two is separation of responsibilities.

Concrete Example of Separation of Responsibilities

For example, imagine building an EC service system. Within this system, there's an order system that accepts orders from users and a warehouse system that manages shipping.

What happens if we build the integration between the order system and warehouse system using an API-driven approach?

First, let's look at the API-driven approach. As shown in the diagram, in the API-driven approach, the order system gives shipping "instructions" to the warehouse system. This is similar to a boss-subordinate relationship - in this case, if some failure occurs on the receiving side (the warehouse system), the order system must handle that error. In other words, the order system bears responsibility for the warehouse system's processing. Moreover, if there's another system beyond the warehouse system, managing that from the order system would be extremely difficult.

In contrast, how about the event-driven approach? As you can see, the order system only fires an event that an order was placed and doesn't care what processes are executed in relation to it.

Conversely, the warehouse system "observes" the order event, and when it's fired, executes the warehouse system's processing. Therefore, in this case, the warehouse system bears responsibility for its own processing.

Reasons for Aiming for Event-Driven Architecture

airCloset's service is realized by integrating many services, which can be broadly categorized into:

Customer-facing system
Authentication management system
Internal management system
Styling system
Inventory management system
Warehouse integration system
Warehouse system
Return system
Payment management system
Accounting management system

(This is just a partial list.)

Currently, these systems are integrated using APIs and batch processes. However, issues arise such as:

API failures in the warehouse integration system causing errors in the styling system
Batch system failures where certain processes fail but subsequent processes still execute, creating inconsistent data

First, we want to eliminate these issues.

Additionally, many current systems are developed assuming they'll be used for the airCloset service, but considering future business expansion, extracting these systems by function and making them available for various services would have significant benefits for both development and operations.

Furthermore, event-driven architecture is similar to how people actually work. For example, airCloset's organization has groups like the marketing group that acquires users, the personal styling group that oversees styling, and the supply chain management group that oversees service operations like warehouses and cleaning. These groups bear their own responsibilities and don't operate through top-down instructions. In this sense, having systems similarly event-driven creates a system closer to reality. Generally, systems that align with real-world operations have better practicality and flexibility, so we want to move toward event-driven architecture for this reason as well.

Disadvantages of Event-Driven Architecture

So far, I've only written about the advantages of event-driven architecture, but of course, there are disadvantages compared to API-driven approaches.

Disadvantage 1: Difficult to Trace Processing

As you can see from the separation of responsibilities diagram, in API-driven approaches, since instructions are passed to coordinate processing, you can trace all processing from the order system in this example. In contrast, with event-driven, systems observing events are invisible from the system firing events, making it difficult to trace the source code.

Disadvantage 2: Logs are Hard to Read

Related to point 1, since each system operates independently in event-driven architecture, it's very difficult to see which processes between systems are working together. In API-driven approaches, you just need to log responses from other systems, so this can be a significant disadvantage.

Disadvantage 3: Difficult to Build

While "difficult" might be misleading, I believe it's harder to build compared to API-driven architecture from both implementation and know-how perspectives.

First, from an implementation perspective, there aren't as many mature frameworks as there are for API-driven architecture. Of course, there are already a considerable number of frameworks and tools, but there's nothing at the level of backend frameworks like Rails or Express that can build API servers very easily.

Also, since there aren't many engineers developing with event-driven architecture, even if implementation methods exist, the lack of know-how makes it difficult to visualize the implementation.

Methods to Realize Event-Driven Architecture

Despite these disadvantages, let's briefly look at what frameworks and tools are currently available.

AWS Services

AWS has several services that can realize event-driven architecture. A characteristic of AWS services is that since AWS services hold the configuration for call destinations, it might be a disadvantage that you can't tell where processes on the event observation side are executed from.

This combination implements event-driven architecture very simply. However, since independent SNS Topics and SQS queues are created for each event with no visible horizontal relationships, it's difficult to adopt as a large-scale system foundation. While it could withstand large scale if well-built with CDK, I'd recommend EventBridge introduced next.

EventBridge

In addition to SNS + SQS functionality, you can define event groupings with EventBus. Also, CloudWatch Events is now part of EventBridge, which is a strength being able to handle them side by side. The ability to handle events from external SaaS applications is also attractive.

StepFunctions

StepFunctions is an event-driven serverless workflow system. It's easy to visualize when using the GUI from the AWS console - you can manage workflows for various AWS services and your own applications. It can also be used in combination with EventBridge mentioned above.

Redis Pub/Sub

Redis has built-in Pub/Sub functionality that can be used as the foundation for event-driven architecture. Pub means Publish (event notification) and Sub means Subscribe (event monitoring). By publishing arbitrary events, pre-subscribed processes are executed.

Google Cloud Pub/Sub

Google Cloud's version of SNS and SQS.

Message Queues like Kafka

Various message queue frameworks can also be used for event-driven architecture.

Summary

I've explained event-driven architecture above, and airCloset plans to gradually migrate to event-driven architecture in the future.

For this purpose, we're actively recruiting engineers who want to challenge themselves with event-driven architecture, so if you're interested, please check out airCloset's Engineer Recruitment Site - airCloset Quest!

Thank you for reading this far! This article marks the end of airCloset Advent Calendar 2022.

Happy New Year everyone!

About airCloset Inc.

airCloset Inc. operates with the mission "Creating new excitement in people's daily lives through ideas and IT," running businesses such as the fashion rental platform "airCloset" and the furniture and appliance rental service "airCloset Mall" where you can try trending products.

The Architecture airCloset is Aiming For