Detailed Component Design

Frontend -

React based on Cloudfront and S3 for static web storage - cloudfront will handle scaling and we can attach a WAF for additional security, cloudfront can easily handle millions of concurrent requests. also this is a CDN which will reduce static file handling to edge locations around the world.

Redirect service -

Lambda with python runtime. all it does is take the hash from the URL, queries ddb table for the target URL value. lambda will have permissions only to that dynamoDB table and will scale on it's own being serverless, all we have to do (also applies to backend service) is to make sure we have enough concurrent lambda invocations in our AWS account quota.

Backend -

Lambda with python runtime. same pros as the redirect service. what it does is generate a 5-6 random hash string which it will store in dynamoDB along with the target URL. we'll set a TTL in that ddb record so we won't have inifite items in our DDB. we'll need ofcouse to adjust for provisioned writes/reads, we can start with on demand table and adjust as needed in terms of scale or use auto scaling.

lambdas will scale horizontaly based on load. HA - tied to a specific region to reduce costs. no need in my opinion to have multiple region setup here. this setup has availability at it's core based on the services selected and is not tied to a specific AZ.
caching - not needed here unless load will reach a crazy scale, DDB is 2-3ms response time, as we mentioned earlier, we are not aiming for ultra low latency that cache like redis would introduce. the only reason we'd want to include cache is if the load on the DB is too high, which we will evaluate if needed.
collision management - backend service is going to query the DDB with the generated hash making sure it doesn't exist already in the DDB.