QR link shortening

LookSuite draws a QR code into the live video, so the drawing cost is paid inside a real-time frame budget. A QR code gets denser as the URL it encodes gets longer, so long links were expensive to draw and looked noisy on screen. Optimizing the drawing would only have moved the cost around. The real problem was the unbounded input.

I changed what the code encodes. The application now encodes a short link, and a dedicated service owns the mapping from the short link to the real destination. The input became short and predictable, so the drawing cost no longer depends on the destination, and every code in the stream benefits.

I treated the redirect as a security boundary. A short link hides its destination from the person scanning it, which makes a silent redirector an obvious route for malicious use. So every short link resolves to an intermediate page that shows the destination and asks the person to continue. Nobody is forwarded anywhere without seeing where.

I built it as an independent service on Cloud Run with its own PostgreSQL store. It had to be separate from the main backend, so it scales and deploys on its own. The redirect is a single lookup of the short link in the database, so it is fast, and the person scanning does not wait for it. The service has its own build and static-analysis checks in the pull-request pipeline, under the same quality gate as the rest of the platform.

Optimizing the QR drawing: it would only have moved the cost, because the payload length sets it.

LookSuite composites a QR code into the live video, so the cost of drawing it is paid inside a real-time frame budget. A QR code gets denser as the URL it encodes gets longer, which made lengthy links expensive to draw and visually noisy. Treated this as an input problem rather than a rendering problem: optimising the drawing would only have moved the cost, while it was the unbounded payload that set it.

Changed the contract. The application now encodes a short link, and a dedicated service owns the mapping from short link to destination. That turned an unbounded input into a short, predictable one, so drawing cost no longer depends on the destination, and every code in the stream benefits.

Treated the redirect as a security boundary. A short link hides its destination from the person scanning it, so a silent redirector is an obvious abuse vector for the product. Every short link therefore resolves to an intermediate page that shows the destination and asks the person scanning to continue, so nobody is forwarded anywhere without seeing where.

Delivered it as an independent service on Cloud Run, separate from the main backend so it scales and deploys on its own, with its own build and static-analysis checks in the pull-request pipeline, under the same quality gate as the rest of the platform.

• It is a new service to build, deploy, secure and keep running, with its own database. That is a lot of process, but it had to be a separate service, so there was no real alternative.
• The scanning person gets an extra step, the confirmation page, as a security control against malicious use.
• The short link depends on the service and its database. In production the service runs more than one instance, so a single failure does not take codes down, but if the whole service is unavailable the code resolves nowhere.

Every QR code in the stream stays sparse, cheap to draw and visually clean, and the drawing cost no longer depends on the destination. Nobody is forwarded without seeing where.