0% found this document useful (0 votes)
18 views4 pages

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

Uploaded by

Sidy Traoré
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views4 pages

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

Uploaded by

Sidy Traoré
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
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