Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL .
  • UI based
  • API based
• Additional :
  • Optionally, provide URL validity
  • Optionally, provide IP based Geo-fencing
  • Optionally, provide other fencing strategies like access window, user agents, automation activity block etc.
• Business Model:
  1. The end user need not provide any JWT key nor needs to authenticate herself for FREE tier.
  2. For paid tiers. however, we may enforce rules.

Non-Functional Requirements:

• Cloud native approach to shift to cloud or on-prem as needed
• Observability - Centralized log tracer, visualizer , event monitoring and alert
• Containers and Orchestrator
• Automatic backup , deployment and rollback

API Design

1. GET /shorten/{url-safe-url}
   1. Ensuring URL safety for the Path Variable {url-safe-url}
2. POST /shorten /{apiVersion}
   1. Payload :

1. 1. Response :

High-Level Design

1. API shortening Service which accepts payload in the above format and responds back, in the happy path, in the above "Response format"
   1. Keeping the shortening strategy decoupled so it can be changed without breaking existing urls
   2. The service stores the API request and response in the DB .
   3. Persistence layer is decoupled
2. Front Controller Routing Service:
   1. Serves inbound traffic to shortened URL .
   2. It uses cache and then a Look up service - hence, is unaware of underlying persistence level
   3. It denies access to the web site based on (optional) fencing rules
3. Persistence Layer :
   1. It decouples underlying database.
   2. Fast and version aware
4. Cache Layer for scalability
5. Event driven middleware to handle updates in fencing rule, version etc.
6. Cross cutting concerns :
   1. server side load balancing
   2. client side load balancing for internal services to interact with each other
   3. Centralized Observability - logging , tracer, event alerts and stats
   4. Auth - we usually keep this provision but mostly leverage to the respective URL owners.
7. Deployment : for scalability , use Docker or an OCI container with K8s or suitable Cloud native platform

Detailed Component Design

1. API shortening Service:
   1. This service exposes an API that generates a JWT with URL safe Base64 encoding
   2. Payload :

1. 1. Response :

1. 1. The "apiVersion" is mainly for auding purpose and to offer flexibility to decouple generation logic by behaviour injection
   2. This stores the API request and response in the Persistence layer without knowledge of underlying database
   3. Transaction between the two services is ensured via Kafka middleware.
   4. The generated URL contains the main URL, fencing rules and API version used.
   5. The end user need not provide any JWT key nor needs to authenticate herself for FREE tier.
   6. For paid tiers. however, we may enforce rules.
2. Front Controller Routing Service:
   1. The Gateway receives HTTP traffic and executes initial cross cutting stuffs
   2. Load balanced routing to Front end controller (this component)
   3. Though we decoupled the logic, we keep this version field embedded within the shortened URL version, using something like JWT with base64 URL safe encoding.
   4. JWT passed:
      1. Apply fencing rules.
      2. On passing fencing rule , route this to the URL
      3. For paid business tiers ,where a second level of security is needed, flow of control is passed on to the persistence latye.
3. Persistence Service:
   1. Database agonistic - but we can use NoSQL faster databases for free tiers where txns are not needed
   2. CQRS pattern for high scalability
   3. Write-ahead-log based database replication & backup using Kafka Dabezium.
4. Cache:
   1. For free users, we do not need any cache since the JWT like shortened URL does not need any db lookup
   2. But for premium business models, for 2nd level safety, we look up the Database if and only if the JWT passes validation and fencing rules/
   3. We use Redis or Hazlecast cluster as distributed cache, subject to need of scaling.
   4. Cache strategy: Read through & event driven
   5. We already have CQRS but if we need to further scale out and reduce latency, we use cache . Overkilling with a new component , is avoided unless it's absolutely necessary
5. Eventing Middleware :
   1. Use Kafka but provision neutrality.
   2. Example- if we use Spring Cloud, we use Spring Cloud Stream instead of using direct Kafka native API code. So, with config changes , we can switch to other broker as needed
   3. Same applies to Dabazium connector - we create a FACADE that does not change despite the Kafka is replaced by say, RabbitMQ
6. Observability :
   1. Centralized Logging : we use somewhat like ELFK
   2. Monitoring : Micrometer -> Prometuse ->Grafana / etc.
   3. Alarm configured via Grafana itself
   4. Still have FACADE for any change - example switching to Splunk cloud etc.
7. Deployment & DevOps:
   1. Docker (or any OCI container) or cloud equivalent like ECR
   2. K8s or equivalent cloud service like AKS
   3. CICD pipeline :
      1. Maven /grtadle - build tool
      2. Artifactory - Eg. JFrog/Apache Archiva
      3. Git based CVS (free on-pre,/ something like Github Enterprise/ Atlassian Bit bucket )
      4. SonarQube etc/- for code quality
      5. CodeSec - SATS. DAST, AppSec , IaC security - tools / services like Checkmarx etc.
      6. Jenkins/ Temcity etc
8. guideline :
   1. Scale out and spend budget
   2. No overkill and over spending.
   3. API first design
   4. Test driven development
   5. Micro services preferred but monoliths are not bad either