Project Topic - Design and Implement A Cloud-Native E-Commerce Platform
Project Topic - Design and Implement A Cloud-Native E-Commerce Platform
Platform
Objective:
The goal of this project is to design and implement a scalable and modular e-commerce
platform that mimics real-world software architecture challenges. By doing so, you will gain
practical experience in making architectural decisions, implementing distributed systems,
and understanding the trade-offs involved in different architectural styles like microservices,
message-oriented middleware, and REST services. You should decide in your group the
specificities of your E-commerce application. Is it a general E-commerce platform, is it a
specialized for specific things (such as spare parts for appliances repairing for example)
Project Breakdown:
This project should be handled by groups of 4 or 5 students. You should produce a
deliverable for at least the 3 first sections. Section 1 and 2 correspond to a document
specifying the set of user stories and the proposed architecture. Section 3 and 4 correspond
to a piece of software implementing parts of your architecture and user stories.
1. Problem Statement:
Design a multi-service, cloud-native e-commerce platform where users can browse products,
place orders, and make payments. The platform should be scalable, fault-tolerant, and
secure.
● User Management: Users should be able to create accounts, log in, update profiles,
and retrieve passwords.
● Product Catalog: A product catalog service should allow browsing of products,
which can be categorized and searched.
● Shopping Cart: Users should be able to add and remove products from a shopping
cart, with the ability to check out.
● Order Processing: An order service should handle order placement and manage
order status (e.g., pending, shipped, delivered).
● Stock management : Stock should be updated according to the orders and a
service to refill the stock should be added
● Payment Integration: Select and include an external payment service. You should
select the external service payment and specify how it will be included in your
application.
2. Architecture Document:
Each group should provide a comprehensive document explaining the architecture they’ve
chosen for their platform. The document should include:
a. Architecture Style:
● Microservices: Why they are using microservices (if chosen). This might be to
isolate functionality, scale individual services independently, or ease of maintenance.
● SOA: If SOA is used, how it compares to microservices in their specific scenario.
● Monolith (if justified): In case a group decides to use a monolithic architecture for
some reason, they need to provide a strong justification.
c. Communication:
d. Scalability Considerations:
● How they plan to scale individual components of the system. For example, scaling
the product catalog independently of the order processing service.
● Load balancing strategies to ensure high availability.
e. Data Storage:
● Database choices, including relational (SQL) or NoSQL systems. Justify the reasons
for choosing either (or both).
● Use cases for eventual consistency or strong consistency models in different parts of
the system (e.g., eventual consistency for product inventory, strong consistency for
payment processing).
f. Security:
● Authentication mechanisms (OAuth2, JWT, etc.).
● Data encryption strategies for sensitive information, particularly user and payment
data.
3. Implementation:
The implementation should reflect the design choices outlined in the architecture document.
Here's what is expected in terms of deliverables:
a. Microservices Setup:
b. Message-Oriented Middleware:
● Use a message broker like RabbitMQ, Kafka, or another SQS for asynchronous
messaging.
● For example, after an order is placed, the order service can publish an event that the
payment service consumes.
c. Persistence:
● Service Discovery & Load Balancing: Implement service discovery for dynamic
service registration (e.g., with Consul or Eureka) and load balancing (e.g., with
NGINX or using Kubernetes for container orchestration).
● Monitoring & Observability: Set up monitoring and logging (e.g., Prometheus,
Grafana for monitoring, ELK stack for centralized logging)
● API Gateway: Implement an API gateway (e.g., using Kong, Ambassador, or AWS
API Gateway) to manage traffic between clients and services.
● Resilience and Fault Tolerance: Implement patterns like Circuit Breakers (using
Hystrix or Resilience4J) to handle service failures gracefully.
Expected Learning Outcomes: