Loading...
POST /api/v1/createAdvert
GET /api/v1/getAdvert?filters&keywords - this when given no filters gives everything with pagination. If we give any filter like title=selling cycle then we will filter the search with that and give the result.
PUT /api/v1/editAdvert
DELETE /api/v1/deleteAdver
POST /api/v1/uploadContent
POST /api/v1/Login - we can use oauth
POST /api/v1/signup - for registration
Database Design:
We will be going to use mongoDB as our database which has the following tables:
Advertisement:
ID - primary Key
Title - Text
Body - Text
AttachmentID - foreign key
CreatedAt - Timestamp
UpdatedAt - Timestamp
Attachments:
ID - Primary Key
Presigned URL - Text
READ PATH:
Client -> CDN -> API Gateway -> Load Balancer -> Advert Service -> Redis -> MongoDB -> Object Store
Write PATH:
Client -> CDN -> API Gateway -> Load Balancer -> Advert Service -> Mongo DB -> Object Store
Advert service handles all the apis related to advert including the search functionality. Along with the indexing done in Mongo using ID and title for better search capabilities.
We will have elastic search with indexing which can be used for searching making our searches fast. It will take in the query parameters and based on that we can display the search results.
The loadbalancer is integrated into the api gateway api paths through a vpc endpoint. Making it possible for communications.
When ever a request comes to an api it will go through the load balancer from there it will go to the respective service. From there if it is a read operation then it will try to get it from Redis if the cache hit is a miss only then it will go to the Mongo DB.
We are going to use an object store here like an s3 service to store the content like images/videos of the advert. We will be using either a presigned url to show display these images or it can be directly integrated into the CDN.
During Burst Traffic the servers/compute where the services are running scale by using simple scaling.
The load is balanced using load balancer
Even before coming to the Redis most of it is taken care off by the CDN.
For write it will go through api gateway and load balancer from there to the respective service which would push it to kafka queue from there the write happens to Redis and Mongo.
This keeps the Cache up to date and stale free.
We have a cleanup service which cleans up the cache in redis and invalidate cdn after ttl expiry.
CDN - We host our frontend in this. I will be able to handle millions of request and is available on edge. It even acts as the first layer of cache where most of the read requests are taken care off. Also we can integrate our object store with this to serve the content files easily.
After an image/attachment is uploaded it will be first processed like resizing and generating a thumbnail and storing it in object store. We will have the associated attachment details filled out in the attachments table.
We can have an idempotency key for each listing to avoid duplicate listings.
API Gateway routes the traffic based on the api that is getting hit. This also helps in rate limiting/throttling of requests which prevents any DDoS and Brute force attacks.
Advert service will have the functionality of search which uses elasticsearch in the background with indexing enabled.
Load Balancer this is configured with API gateway and is used to distribute the load across the servers hosting our services. Keeping the traffic uniform and capable of handling the spike in traffic.
Kafka Queue - Takes in the events that the services create and pushes the data into the DB and Redis. Even though if a service goes down it can continue where it left off since the queue will have the data that needs to be processed there by having our graceful degradation.
Cleanup Service - Service used to keep the redis cluster clean by removing the rows after ttl expiry. Can also invalidate the cache in CDN.