TinyUrl - Evolving design with requirements

Most of us have designed a tiny url service multiple times, yet I found it instructive to observe how my design changed as I walked through a list of requirements that a service like tiny url generator system could experience as it grows over the years.  How does your design for tinyUrl service changes as you walk thru these requirements?

1. Design a simple tinyUrl service (makeTiny, lookup) for use within your team for quickly sharing long url's on Im during conversation.
2. Extend the service to allow url's to stay valid for a long time
3. Extend the service to allow users to add a optional "human-sensible" end token for ease of discussion
4. Extend the service to auto add a human readable word to end to ease discussion
5. Scale the system up - for use across the entire company
6. Scale the system up for offering it as a web service
7. Extend the system so that customers' data is never kept on durable storage(DB/file etc) in plain text.
8. Extend the system to that customers' can specify their own encryption key
9. Extend the system so that customers' can rotate their keys at will
10. Extend the system to auto rotate keys every day for the customers
11. Extend the system so that customers can create tiny url's that stay valid only for X days
12. Extend the system so that customers can create tiny url's that are valid only for first X clicks
13. Extend the system to enable reporting queries by our business analyst.
14. Our business analyst found that most url's are accessed within 7 days of creation and rarely afterwards. How would you modify the system to reduce TCO in light of this
15. Our service has become famous. CIA wants to use it, but it wants us to persist data in their data center only. How would you change  the system to support this?
16. CIA wants to limit IP's from which its tiny url's can be looked up. How would you modify the system to support this requirement?
17. We found the occasionally our service puts inappropriate words in url (#req 4). Change the service to remove such poorly generated url's.
18. We are encoding billions of urls now. Our tiny Url generation protocol occasionally leads to bad words which causes reputational damage for us. Change the service to remove such poorly generated url's.
19. Estimate the latency of your system. How would you make it faster?
20. Our service is getting misused. Mafia is using it to hide messages in url itself. FBI wants us to send them a message everytime the big incoming url contains certain key words. Extend the system to do this.
21. Our service is now a paid service, but customers feel our prices are too high. So, We want to support a new class of customers - Customers who are willing to accept occasional data loss (not able to find big url corresponding to tiny) in return for cheaper pricing. How would you extend the system to reduce its hardware cost for such customers.
22. We are not making enough money. So, we want to sell some advertising on our website. As a result now each lookup request would first show an ad and then redirect the customer to the actual url. Design a system that chooses ads ( from all ads in our db) to be showed to the customer when he does a lookup. Note that makeTiny is still ad free.
23. Our advertisement volume has grown, and we have a number of advertisers. They want to be able to supply their own algorithm for choosing the ads rather than use our system logic.
24. So far we have been charging customers' a fixed rate for each ad display. Modify the system so that advertisers' can bid on requests in real time and the winning advertisers' ad is displayed
25. Extend the system to support self service advertisers.
26. We found some self-service advertisers' are showing inappropriate ads. Such ads rarely get clicked. Enhance your system to ban advertisers whose ads don't get clicked at all
27. Our advertisers want to be able to see how many of their ads got clicked. Extend the system to generate these metrics.
28. Extend the system to enable advertisers to set up daily reports indicating how many times each of their ads were displayed, how much did it cost them, and how many times each of those ads were clicked.
29. Our advertisers want to estimate their monthly expenses in advance so that they can plan budgets. Can you extend the system so that advertisers can see their monthly spending trends.
30. We found that we have some bad advertisers. They buy ads, but then their credit card doesn't work at month end, and we are unable to charge them. Extend the system so that customers get charged every night and if the transaction fails consecutively for 3 days, then their account gets suspended until there account is cleared.
31. Extend the system so that those whose accounts got suspended, have to deposit money in advance for their ads to display.
32. We have a new offering to our customers. Those who pay our subscription fees, they wont have to see an ad to access the tiny link. Modify the system to not show ads to such customers.

Thanks

Umesh