Here are some important architectural guiding principles we are following:

1. “If you cannot Split it, you cannot Scale it”. This came from a great EBay architecture presentation during a SDForum session in Palo Alto in November of 2006. (Presentation: How eBay Scales Presentation)
2. Statefullness is the enemy. This is one of the reasons why we avoid any framework that assumes states between the client and the servers. This is not to say that client cannot store some states, but rather than the client cannot assume that the server will remember them.
3. “Start simple, end simple”. In other words, “keep it simple.” However, we recognize that at some points in the design lifecycle, some components could become a little complex; the goal should be to eventually simplify them.

Principles are hard to always follow, but they are here for a reason… keeping us disciplined. So far, we are not doing too bad at following these principles, but we know we will have some work to do on the database side. The whole trick is to scale cheap…

On the geeky side, here is some information about application platform choices we made. First, we have decided to write all of our server code in Java. While other development platforms sound attractive, we think that Java has come a long way from its heavy and complex days, and now offers a very complete and mature set of tools and libraries for high scale consumer applications. Find below a snapshot of our current application architecture:

From a bottom to top:

1. MySOL 5 and FileStore are used for data and file storage. At this point we are not clustering the database, and have a simple “File Segmentation” based on user ID’s. Long term, we will have to find a way to “split or cluster” the database.
2. Java 1.6: We were pretty satisfied with Java 1.5, but Java 1.6 seems to perform better, and includes Jaxb2.0. It’s also good to start your development/production cycle with the latest version.
3. Tomcat 6.x: We picked Tomcat 6.x mainly for the reason above (i.e., to start with the latest version). We do not really use any deep Servlet or JSP features at this point. So far, we have been very happy with Freemarker, and our first JSP 2.1 evaluation showed that it still did not meet some of our requirements (e.g., template in the database).
4. Hibernate 3.2: Who would not use Hibernate 3.2 when developing a database-driven application? Actually, there might be some reasons to not use it, but for now, we have determined that the cost/benefits analysis favors using it. We know we will have to optimize the SQL Statement some day. However, we also think that if we want to scale, we will have to cache, which will make the O/R performance issues not such of a bottle neck.
5. Lucene 2.x: Who would not use Lucene to provide search capabilities? There might be some reasons, but we do not know about them. We might use it for our cache strategy as well (not sure yet).
6. Jaxb2.0: This is actually part of Java1.6 now, but from an architecture standpoint, it belongs to this level. While Jaxb1.0 was a typical “EJB2.1 over-designed” library, Jaxb2.0 takes advantage of annotation to simplify a lot the marshalling and unmarshalling rules. We have not done heavy performance testing yet, but the new APIs work like a charm (no need to specify Schemas anymore!)
7. AspectJ 1.5: We are big fans of Aspect programming. However, given that it is not part of the Java language, we are using this library very cautiously, mostly to propagate Interface implementation such as CreationStamp and UpdateStamp. We are using AJDT for Eclipse, which works very well, except for a little bug which is very frustrating. Sometimes we have to clean the project to be able to compile, so it does get frustrating after a while… looking forward to Eclipse 3.3.
8. Freemarker: Freemarker is a modern template engine a little bit like Velocity but more “modular”. It is extremely extensible, and flexible, and while JSP2.1 has some nice features, Freemarker is still the most flexible and mature Java template engine that we know of.
9. Yahoo! UI: For business and usability reasons, our application will follow the common “web page model”, but it will also offer some subtle and advanced AJAX interactions. Yahoo! UI is a solid and complete AJAX framework to incrementally add dynamic behavior to your web page. At this point, we are not sure how many of the standard Yahoo! UI widgets we will be using, but we will definitely use their core libraries. At some point, we might make some more advanced components, and Adobe Flex will be a natural fit for those.

Sportner’s architecture has two main layers:

1. Universal Service Platform (AKA USP): This is not a “Universe Universal” but rather a “Sportner Universal” platform. Basically, this layer contains all of the generic parts of the system that do not have any specific connection with the given “Sportner” application. This allow us to have a clean abstraction, and to have a platform upon which we can build auxiliary applications if necessary (we started to write a “Name Finder Application” during our days of desperation).
2. The Sportner Application (AKA SPR): This is the main Sportner application on top of the USP layer. It has all of the templates and logic specific to the application.

This architecture is pretty basic. The trick is to find the right compromise between using existing libraries and building the right infrastructure. One thing that people could ask us is why we are not using Spring? The main reason is that we do not need it yet. Our first quick look at some Spring components showed us that they might be overdesigned for our needs (at least for now). Our “USP” Layer is very thin, and we are working to make it thinner. At this point, we do not really need more. Time will tell, we are open minded (at least, we try to be).