0% found this document useful (0 votes)
10 views

Project Topic - Design and Implement A Cloud-Native E-Commerce Platform

Uploaded by

Sidy Traoré
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views

Project Topic - Design and Implement A Cloud-Native E-Commerce Platform

Uploaded by

Sidy Traoré
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Project Topic: Design and Implement a Cloud-Native E-commerce

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.

Example User Stories:

● 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.

b. Example Key Components:

● User Service: Handles authentication, authorization, and user management.


● Product Catalog Service: Stores product data and exposes search and filtering
APIs.
● Order Service: Manages orders, including statuses, inventory checks, and invoicing.
● Payment Service: Processes payments and integrates with third-party APIs
(simulated for this project).
● Stock management: Manages Stock according to orders and refills from stock
providers.
● Notification Service: Optional – sends notifications to users (email or SMS, using
message queues).

c. Communication:

● Synchronous vs. Asynchronous Communication: What are the communication


strategies between services? For example, REST APIs for synchronous
communication or message brokers (e.g., RabbitMQ) for asynchronous tasks like
order confirmation.
● Message-Oriented Middleware: If they use message queues, explain their role in
decoupling services (e.g., order service publishing events and payment service
consuming them).

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:

● Implement at least three microservices (e.g., User, Product Catalog, Order).


● Use REST API for service-to-service communication.

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:

● Set up data storage (e.g., PostgreSQL, MongoDB, etc.).


● Ensure each service has its own dedicated data store, reflecting microservices best
practices (database per service).

e. Containerization & Deployment:

● Containerize the services using Docker.


● Set up a CI/CD pipeline to deploy the services automatically (preferably using cloud
platforms like AWS, Azure, or GCP).

4. Bonus Features (Optional but Encouraged):

● 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:

1. Architectural Decision-Making: You will learn to evaluate and choose between


different architectural styles and patterns, understanding their strengths and
limitations.
2. Practical Microservice Implementation: You will gain experience in implementing
distributed systems, where services communicate over the network.
3. Scaling and Fault Tolerance: You will understand how to build systems that scale,
handle failures, and recover from issues.
4. Cloud-Native Practices: By deploying on the cloud or simulating cloud-native
environments locally, you will experience modern DevOps practices like
containerization, CI/CD, and automated deployment.
5. Collaboration and Documentation: Working in teams, you will improve their
collaboration skills and learn to document architectural decisions in a professional
format.

You might also like