Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.
• The url will be stored for 3 days
• If the url already exists, it can return the same value
• Same url can only have limit of 50 requests per minute

Non-Functional Requirements:

• low latency - every endpoint must have low latency, get must be under 300 ms and post must be under 500 ms. Both must have 95% of acceptable time requests
• high availability - the system cannot be down even if we have deployments
• Every service must have at least 2 tasks for redundancy
• Horizontal scalabilitty:
  • Every task must have auto-scalling configured, if it has over 80% of memory or cpu consumption it must start one new task, if it has under 40% of memory or cpu consumption it must stop one task
  • The database must aways be available, as dynamodb, it can be used sharding
  • Every servicemust have a load balancer to controle the traffic between the tasks defined in ecs cluster

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST /shorten

• URL create to receive a url and return the shorten url

GET /{id}

• Receive the id and redirect to page

High-Level Design

Clients: Users or apps that will use the url shortening service

API Gateway:

• Entry of the point for requests. It will have a rate limit implemented to avoid attacks.

Shortener service:

• The service resposible for shortening the url and return the new url for client. When the client requests POST /shorten, the api-gateway will redirect to this service.
• To create the shortened url, we can use the snowflake_id (hash these values: machine_id, timestamp, sequence).
  • The machine_id will be the hash of taskArn
  • The timestamp will be at current time
  • sequence is based on same timestamp and always will reset on next timestamp

redirect-service: Service responsible for search the url by the code and redirect to the page. It will use caffeine cache for local cache to reduce load in database

database: dynamodb, will store the id of url and will be de primary key and the original url. It will use horizontally scalabilty, will priorize availability than consistency.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Function of shortener service:

• The shortener services generates the id of the link to bound with the original link
• To generate the id is used the snowflake_id algorith.
• it will be the combined hash of theses attributes
  • machine_id: based on taskArn, witch will be only one by machine, 2384each task runs in one machine
  • timestamp: current timestapm
  • sequence: the sequence based on timestamp, witch means that if one url is asked to be shortened at same timestamp at same task, it will be increased by 1, if the timestamp chances the sequence will be reset to 0
• This three properties combined garantees that a url never have the same id

redirect-service

• the redirect service will use a local cache. If the id will not be found on cache, it will search the data on database

Database

• It will be dynamodb
• it will use the id as pk
• this database will focus more on availability than consistency
• It will use the horizontal scalability and eventual consistency
• It will be configured with ttl of 3 days