CareerCup

A 2 level hashing should be sufficient.
a) HashMap<int,HashMap> person = new HashMap<int,HashMap>();
b) The second HashMap will map a pageId to its frequency.
HashMap<int,int> pages = new HashMap<int,int>();

void incrementFrequency (int personId, int pageId){
   HashMap pageMap = persons.get(personId);
   pageMap.set(pageId, 1+pageMap.get(pageId));
}

Some null checks will also be required.

all the user's usage will be tracked in a separate file per user. File name could be userID.log. Inside the file data will be stored as HashMap.

HashMap getUsageStats(String userID){
//<URL, Count>
HashMap<String,Integer> usageMap = new HashMap<String,Object>();
if (TextUtils.isEmpty(userID) return null;

File file = new File(userID);
FileInputStream f = new FileInputStream(file);
ObjectInputStream objFile = new ObjectInputStream(f);
usageMap = (HashMap<String,Object>)objFile.readObject();
objFile.close();
return usageMap;
}

A btree structure would be good for storing users, where each node can be on separate machines.

For instance, Machine 1 might contain info for all names. If your name leads off with letter A, it will forwards you to machine 2, B machine 3, etc.. You might need many many copies of machine 1 to handle all the requests since essentially machine 1 is at the root of the tree. At machine 2, you might forward based on the second letter in the username, AB -> machine 4 AC -> machine 5 etc. The amount of splitting depends on distribution of naming patterns. Also, the number of machine clones you need depends on which level you are on the tree. Nodes further down will need less clones while nodes at the top will need more to handle more traffic. This will reduce the number of searches for a user to be dependent on the length of the username than the number of users. Obviously, the same principal works if there is a mapping function from username to a numerical ID where a B tree is even more intuitive.

Once we get a match for a specific user, we can then access the specific usage frequency tree of the user. In this case, we can store the usage frequency as a binary hash map. A user is unlikely to have a huge amount of different websites visited, so we don't have to worry as much about a huge tree and lookup/update. We should probably cache the location of user specific frequency tree so that we don't have to dig through the hundreds of millions of user every time a user clicks on a new page and make the cache decay in time as hits often will bunch up in the time space.

I think an important aspect of thinking of these problems is scaling and parallel/distributed processing. Obviously, many web scale solutions will never be able to run one a single machine so algorithms have to be adapted.

User object to contain the Page details
Something like

class User {
    int userId;
    Map<int, int> pageVisits; //<pageId, frequency>
};

Now create a hashtable for storing User objects