Een URL-shortener ontwerpen

Welkom! In deze les ontwerpen we een service voor het verkorten van URL's, vergelijkbaar met Bitly of TinyURL. Deze services nemen een lange, complexe URL en zetten deze om in een veel kortere en beter hanteerbare URL.

URL-verkorters zijn bijzonder handig om links te delen op sociale media, in e-mails of overal waar de ruimte beperkt is. Ze bieden vaak ook analyses, waarbij wordt bijgehouden hoe vaak er op een verkorte link wordt geklikt.

Een URL-verkorter voert voornamelijk twee belangrijke functies uit:

• Verkorten: Neemt een lange URL als invoer en genereert een unieke, korte code. Deze code wordt vervolgens gebruikt om de korte URL samen te stellen.
• Doorsturen: Wanneer een gebruiker een korte URL opent, zoekt de service de bijbehorende lange URL op en stuurt de browser van de gebruiker daarheen door.

Deze twee bewerkingen vormen de basis van het hele systeem.

De kern van een URL-verkorter is de mogelijkheid om unieke, korte en vaak voor mensen leesbare codes te genereren. Veelgebruikte aanpakken zijn:

• Sequentiële ID's + Base62-codering: Gebruik een automatisch oplopende database-ID en zet deze om in een Base62-tekenreeks. Base62 gebruikt 0-9, a-z en A-Z (62 tekens), waardoor kortere codes mogelijk zijn dan met Base10.
• Hashfuncties: Pas een hashfunctie, zoals MD5 of SHA256, toe op de lange URL. Gebruik een deel van de hash om de korte code te vormen. Hierbij moet je botsingen afhandelen.
• Willekeurige tekenreeksen genereren: Genereer een willekeurige tekenreeks met een vaste lengte. Ook hierbij moet je de uniciteit controleren om botsingen te voorkomen.

Bekijk een eenvoudig Python-voorbeeld van Base62-codering. Dit is een populaire methode om korte codes uit sequentiële ID's te genereren. Zo blijft de uniciteit gewaarborgd en blijven de codes compact.

Om onze URL-koppelingen op te slaan, hebben we een database nodig. Een eenvoudig schema kan er als volgt uitzien, met een relationele database zoals PostgreSQL:

• id: Primaire sleutel (automatisch oplopend geheel getal)
• short_code: VARCHAR(10) - De unieke korte tekenreeks
• long_url: TEXT - De oorspronkelijke, lange URL
• created_at: TIMESTAMP - Wanneer de korte URL is aangemaakt
• user_id: INT (optioneel) - Als gebruikers accounts kunnen aanmaken
• click_count: INT (optioneel) - Voor eenvoudige analyses

Een NoSQL-database kan ook werken en biedt flexibiliteit bij de ontwikkeling van het schema.

Wanneer een gebruiker op een korte URL klikt, zoals https://tiny.url/abcde, neemt de doorstuurservice het over. Deze voert de volgende stappen uit:

1. Haalt de short_code, bijvoorbeeld abcde, uit de URL.
2. Vraagt de database op om de bijbehorende long_url te vinden.
3. Stuurt een HTTP-omleidingsantwoord 301 (Moved Permanently) of 302 (Found) naar de browser van de gebruiker, met de long_url als doel.

301 versus 302: 301 is bedoeld voor permanente omleidingen en wordt door browsers in de cache opgeslagen; 302 is tijdelijk. Voor URL-verkorters heeft 301 vaak de voorkeur vanwege de prestaties na de eerste aanmaak.

Het is essentieel dat elke gegenereerde korte code uniek is. Als we hashfuncties of willekeurige tekenreeksen gebruiken, zijn botsingen mogelijk: twee verschillende lange URL's krijgen dan dezelfde korte code. Bij langere codes komt dit zelden voor.

Strategieën om botsingen af te handelen:

• Databasecontrole: Probeer de nieuwe koppeling altijd in te voegen en vang een schending van de unieke beperking op. Als er een botsing optreedt, genereer je de code opnieuw en probeer je het nogmaals.
• Vooraf controleren: Vraag vóór het invoegen de database op om te controleren of de code al bestaat. Dit kan bij hoge gelijktijdigheid leiden tot racecondities. Unieke beperkingen op databaseniveau hebben daarom de voorkeur.
• Gedistribueerde ID-generatie: Gebruik voor sequentiële ID's een gedistribueerde ID-generator, zoals Snowflake ID, om wereldwijd unieke ID's te garanderen die vervolgens met Base62 kunnen worden gecodeerd.

Een populaire URL-verkorter moet miljoenen verzoeken kunnen verwerken. Belangrijke punten voor schaalbaarheid zijn:

• Database: De database wordt een knelpunt. Overweeg om de database te sharden op basis van short_code of een gedistribueerde sleutel-waardearchief te gebruiken. Leesreplica's zijn essentieel voor de doorstuurservice.
• Caching: Sla vaak opgevraagde koppelingen van korte naar lange URL's in de cache op, bijvoorbeeld met Redis of Memcached, om de belasting van de database te verminderen, vooral voor het doorstuurpad.
• Asynchrone verwerking: Stuur voor klikanalyses klikgebeurtenissen naar een berichtenwachtrij voor asynchrone verwerking, in plaats van een teller synchroon te verhogen.
• Load balancers: Verdeel binnenkomend verkeer over meerdere instanties van je verkortings- en doorstuurservices.

Naast het verkorten bieden veel services eenvoudige analyses. Zo houd je klikken bij:

• Wanneer een korte URL wordt geopend, verhoog je click_count in de database voor die specifieke koppeling.
• Bij veel verkeer kan het bijwerken van deze teller een knelpunt worden. Een beter schaalbare aanpak is om een bericht naar een wachtrij te sturen, zoals Kafka of RabbitMQ, en een afzonderlijk werkproces de aantallen asynchroon te laten bijwerken of gedetailleerde kliklogboeken te laten opslaan.
• Voor gedetailleerde analyses kun je onder andere de verwijzende pagina, user-agent en het IP-adres opslaan in een afzonderlijke analysedatabase, zoals een datawarehouse.

We hebben de belangrijkste onderdelen van het ontwerpen van een URL-verkorter doorlopen!

• We hebben de twee hoofdfuncties behandeld: verkorten en doorsturen.
• We hebben methoden voor het genereren van unieke korte codes onderzocht, zoals Base62-codering.
• We hebben het databaseschema voor het opslaan van koppelingen en de werking van de doorstuurservice besproken.
• We hebben belangrijke aspecten behandeld, zoals het afhandelen van botsingen, schaalbaarheid met caching en sharding en eenvoudige klikanalyses.

Deze casestudy laat zien hoe verschillende principes van systeemontwerp samenkomen om een functionele en schaalbare service te bouwen.