Architecture Overview for WMS

This document details the agent-based architecture in which autonomous agents react to events, making changes to their internal state. The focus of this architecture is scalability and
high maintainability. With this architecture, we want to address a dynamic and complex field of “warehouse management," which requires the application to be highly maintainable to adapt to
changes and scalable to allow for massive throughput.
(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f7nmyrosqsagzxthpvrh.png)

System Components

*Client Layer *
The client layer includes the frontend application, which interacts with the backend via the Ocelot API Gateway.

React SPA
The front end for the web will be implemented using React SPA. We had other options
like ASP.NET MVC/Angular, but we chose React based on the following criteria.

• Its modular component-driven design makes the app more maintainable
• Reusable components help us write less code for the same functionality
• Powerful libraries are available to implement complex functionality
• Loose coupling of backend and UI
• Designed for an API-first system

There are also some challenges with react some are,

• Hard to think the right way
• Less experienced team with React

API Gateway

The API gateway will be implemented using .NET Core and the Ocelot Library. Ocelot is a more mature and feature rich library than its alternative YARP, so we opted for using Ocelot for our gateway. The following are the responsibilities of the gateway.

• Acts as reverse proxy and manages request routing to backend microservice
• Handles authentication, rate-limiting, logging and load balancing
• Converts HTTPS request to HTTP which offloads SSL encryption and decryption for the microservices

Microservice Agents

Microservice agents are autonomous agents maintaining their own data which can be
deployed and scaled independently. The following different agents are identified initially
for WMS which can further be merged or further decomposed in the future based on the
needs,
Agent
Inventory Agent: Manages inventory-related operations (stock updates, product listings).
Receiving Agent: Handles inbound shipments, verifying received goods.
Storage Agent: Manages storage allocation, retrieval, and warehouse space tracking.
Shipping Agent: Handles picking, outbound logistics, tracking shipments and deliveries.
User Identity Agent: Manages user authentication, roles, and permissions.

Communication Protocols

The architecture will support the following methods for communication between the services.

Synchronous Communication using REST

REST communication is generally kept at a minimum between services. REST methods are used in following scenarios:

• Implementing simple service to service communication
• When instant feedback is required
• Use mostly for read operation

Asynchronous Event Based Communication using RabbitMQ

Use event-based communication for following scenarios:

• Trigger background jobs
• Propagate changes between services
• Distributed transactions

Observability and Monitoring

Open telemetry is used as an observability framework, the data generated by open telemetry (logs, metrics, and traces) are displayed by the .NET Aspire Dashboard for local environments, and for production, they are managed by Loki for logs, Grafana for visualization, Tempo for traces, and Mimir for metrics. This stack is popular for persisting and searching through the logs.

Deployment Strategy

The following things are our deployment strategy:

• Single service per repository
• Single CI/CD pipeline per service
• Single Container per service

For local deployment, .NET Aspire is used, and for deployment, each service. The microservice will be deployed to a Kubernetes cluster.