10 Years of airCloset System Architecture and Beyond

This article is an English translation of the original Japanese article published on Zenn.

Hello everyone! I'm Tsuji, CTO of airCloset.

It's hard to believe that 10 years have passed since we launched our service in 2015. From the very beginning, we received an overwhelming response far exceeding our expectations, and we've grown into a service used by many customers. The system that has supported this rapid growth has also evolved significantly alongside our business.

Today, I'd like to share our technical journey over these 10 years, how we've evolved our system to support our unique "circular logistics" business model, and where we're heading next.

The Unique Technical Challenges of Circular Business

airCloset's business model is fundamentally different from typical e-commerce sites. Rather than simply delivering clothes to customers and ending the transaction, we create a cycle of "rental → return → cleaning → rental again." This circular logistics required custom system development that couldn't be achieved with existing e-commerce platforms.

The Complexity of Individual Item Management

While typical e-commerce manages inventory at the SKU level, we need to track "this specific item" - where it is and what state it's in. Is it in the warehouse? Being delivered? With a customer? Being returned? Being cleaned? We assign unique IDs to each item and manage their state transitions, which became the foundation of our system.

Implementing Complex Business Workflows

Furthermore, we needed to incorporate fashion business elements beyond just logistics - professional stylists selecting coordinates based on each customer's preferences, body type, and usage scenarios. Styling logic, inventory allocation, and delivery optimization all need to work together seamlessly.

10 Years of Technical Evolution

Phase 1 (2015-2017): Battling Explosive Growth

The launch in 2015 was an unforgettable shock. We started with an externally developed Rails system, but received 25,000 registrations - far exceeding our expectations - and the system completely crashed. This crisis prompted us to rebuild the system in just 10 days.

Within the first year, we completely migrated to an in-house Node.js-based system. At this point, we had a typical configuration: customer-facing system, internal management system, and batch systems running scheduled tasks like warehouse integration and monthly billing. Node.js was still a new technology with limited enterprise adoption, but we believed JavaScript's asynchronous processing was perfect for real-time inventory management and order processing. This choice proved to be correct.

Phase 2 (2018-2020): Strategic-less Fragmentation - Challenges and Lessons

As the business grew rapidly, we further divided our existing responsibilities. We separated the styling system from the internal management system, split the warehouse integration system from the batch system, and extracted the item management system as an independent application.

However, this division lacked consistency. Some systems had their own databases while others continued using shared databases, resulting in a half-baked state. We thought "systems should be divided by responsibilities" but proceeded without a clear future vision, losing architectural unity.

Looking back, many things didn't need to be separated, and some actually became more complex after separation. We learned that "division itself shouldn't be the goal" and "architecture needs consistency."

Phase 3 (2021-2023): Seeking the Ideal Architecture

When our fragmented systems grew to over 10 applications, the problems of inconsistent configuration became apparent. With a mix of systems with independent databases and those using shared databases, we faced fundamental questions: How do we maintain data consistency? Where do we set transaction boundaries?

Furthermore, synchronous API calls between services meant failures cascaded. Excessive division increased operational complexity. The lack of architectural consistency made it difficult for new engineers to understand the overall picture.

Facing these problems, we sought a fundamental solution. Around 2022, we concluded that "event-driven architecture is the ideal system." (Details about this thinking are covered in our 2022 article)

With event-driven architecture, each system operates autonomously and shares necessary information asynchronously through events. This minimizes dependencies between systems and limits the scope of failure impacts. Learning from past failures, we began migrating to a more robust and flexible architecture.

Phase 4 (2024-2025): Event-Driven Challenges and Achievements

In traditional API-driven systems, the order system directly "instructs shipping" to the warehouse system. In event-driven architecture, the order system simply fires an "order placed" event. The warehouse system observes this event and processes it autonomously.

This change achieved loose coupling between systems and limited failure impact scope. It also made adding new services easier, significantly improving business flexibility.

In fact, in 2024, leveraging this event-driven foundation, we launched the dress rental service "airCloset Dress" in just 3 months. With about 20% of the resources compared to traditional development methods, we implemented all necessary features for a rental service: member registration, cart, ordering, item management, and warehouse integration. This achievement was only possible because our common foundation was designed with event-driven loose coupling. (Details are covered in this article)

Philosophy on Technology Selection

"There Is No Ultimate Architecture"

The most important lesson from 10 years of system development is that "there is no ultimate architecture." The optimal architecture varies depending on service characteristics, team capabilities, and business requirements.

In our case, we needed to evolve our system to match our unique circular logistics business model. Rather than blindly applying industry best practices, it's important to customize them to fit our business optimally.

Align Systems with the Real World

Another important lesson is that "systems are more practical and flexible when aligned with real-world operations." By matching organizational structure with system structure, each team could operate autonomously, improving development speed.

For example, when the styling team wants to add new features, they don't need to wait for approval from other teams. Since each service is independent, they can develop at their own pace.

Approaching Technology Trends

The technology world evolves daily. New frameworks, new architectural patterns, new tools. It's impossible to chase everything, nor is it necessary.

What's important is identifying technologies that truly add value to our business. For example, we adopted event-driven architecture not because it was trendy, but because it was necessary to solve our problems.

10 Years with Node.js

Why We Chose Node.js

When we started with Rails in 2015 and migrated to Node.js within the first year, Node.js was still a new technology. While many companies chose Java or Ruby, why did we decide to migrate to Node.js?

The main reason was that the asynchronous processing paradigm suited circular logistics. Node.js's event loop model was perfect for our system where inventory states change in real-time and multiple processes run in parallel.

Evolving with Node.js

Over these 10 years, Node.js has evolved significantly. From callback-based processing to Promises, and then async/await. This evolution dramatically improved code readability and maintainability.

We've also improved our codebase alongside Node.js's evolution, gradually replacing legacy code with modern patterns, evolving into a more maintainable system.

The Importance of Performance Tuning

Node.js delivers high performance when used properly, but misuse can hinder system performance. For example, executing many synchronous processes or causing memory leaks degrades overall system performance.

We regularly conduct performance analysis, identify bottlenecks, and make improvements. The accumulation of steady improvements like utilizing stream processing, appropriate caching, and database query optimization supports our stable system today.

Co-evolution of Organization and Architecture

Fostering Engineering Culture

Ultimately, people support technical evolution. We value a culture where engineers make autonomous technology choices and can challenge themselves without fear of failure.

Regular study sessions and participation in advent calendars have established a learning culture. This culture has enabled us to continuously evolve for 10 years.

Future Outlook: Toward the Next 10 Years

Complete Migration to Event-Driven Architecture

We're currently proceeding with a phased migration to event-driven architecture. This isn't just a technical change but a strategic choice to increase business flexibility.

Event-driven architecture makes adding new services easier and minimizes impact on existing services. It also limits failure impact scope and improves overall system availability.

Evolution to Multi-Service Platform

airCloset is evolving beyond just clothing rental to a platform supporting overall lifestyle. Therefore, each system component is designed to be reusable for other services.

We're preparing an environment where we can quickly launch new services by standardizing core components like authentication infrastructure, payment systems, and logistics systems.

Co-creation with AI: Adapting to the Vibe Coding Era

Since 2024, we've actively started using AI technology. With Claude Code Max rollout to all engineers, development productivity has dramatically improved. GitHub research shows AI can improve coding speed by 55%, and we're experiencing these benefits firsthand.

However, AI is just a tool. What's important is what we achieve using AI. In the age of generative AI, engineers need not just coding ability but skills in upstream processes like requirements definition and design, plus the ability to understand and modify AI-generated code. (This perspective is detailed in another article)

Promoting Full-Stack Engineering

Since our founding, we've valued not dividing roles by technical domain. This philosophy of "full-stack engineering" truly shines in the AI era, we believe.

While AI has accelerated individual tasks, coordination costs between teams remain unchanged. In fact, as development speed increases, coordination frequency increases, often becoming the overall bottleneck. Full-stack engineers, understanding the entire system, can act as "conductors" of AI, properly judging which parts to delegate to AI and where human judgment is necessary.

Indeed, in developing airCloset Dress, it was because full-stack engineers understood the entire system and could efficiently divide responsibilities that we achieved such a rapid launch. With specialized division, inter-team coordination alone would have taken twice as long.

Development Culture Emphasizing Communication

Precisely because we're in the vibe coding era, we value real-time communication. As AI takes over coding, the engineer's role shifts from "How (to implement)" to "Why (to build)" and "What (to build)."

And to deepen Why and What, close communication is essential. Consultations starting with "Got a minute?", discussions at the whiteboard, ideas born from hallway chats - these values cannot be fully replicated remotely.

We have systems to facilitate communication: everyone uses nicknames, weekly all-hands meetings, semi-annual retreats. We believe the optimal model for AI-human collaboration realizes by valuing both technology and humanity.

Contributing to the Tech Community

We'll give back our 10 years of experience to the tech community. Through open source contributions and advent calendar participation, we want to contribute to the tech community's development by widely sharing our insights.

Conclusion: The Future of Technology Created by Circular Business

airCloset's 10 years have been a decade of business and technology evolving together. The unprecedented business model of circular logistics brought us technical challenges, and through solving them, our unique system architecture was born.

"There is no ultimate architecture" and "align systems with the real world" - these beliefs come from our 10 years of experience. Not technology for technology's sake, but technology for business success. That's what we aim for.

We'll continue to embrace technological evolution and constantly seek optimal choices. The migration to event-driven architecture is a big step toward the next 10 years.

Finally, I'd like to thank everyone who has supported us over these 10 years. And we eagerly await engineers who will take on new challenges with us. If you're interested, please check out our engineering recruitment site "airCloset Quest".

Creating new ways to enjoy fashion through the power of technology. That challenge has only just begun.