Under the hood www.miljoparkering.se is, admittedly, quite overdesigned.

The web site, in its current form, is very simple: People sign up. They then choose the streets they want reminders for. It’s also possible for them to change their e-mail address. Every night there’s a recurring job that goes through all the user profiles, matches them with street cleaning tasks for the day, and then send out reminders to the users that has these streets selected. The site could have been made easily in a short time with a simple relational database, simple data access layer and some CRUD code.

For the last year or so, however, the Command Query Responsibility Segregation (CQRS) principle and Event Sourcing has been surging up the trend curve. It’s hard get around if you’re interested in system design. Many people talk about it, it’s discussed on community meetings. We actually considered CQRS when we had to make initial technology choices for Mikz.com, the daytime project I’m currently working on. But CQRS+EventSourcing is quite different than the classic de-facto enterprise system design, the n-layered design.

In a n-layered design, you’ll typically see at least three layers, UI, domain logic and database access. Depending on your flavor, you might have more layers, and the data access layer might / might not be implemented with and ORM framework such as nHibernate. After changes changes are made to the domain model, the current state of the model is persisted into the database. When you need to get information from the system, the same layers are used to query for the current state.

In CQRS, you don’t use the same model for both updating and for querying. There’s a model that facilitates safe and structured changes to the domain objects (through the use of “void” commands). And there’s a model for querying the system. The first model may be relatively slow to work with, but that’s ok because we need to validate the information and ensure that the changes are made correctly, and we maybe even have notify other systems that a change has occurred. The read model, however, generally needs to be fast since most often, for each update you make to a system, there are many reads.

Creating a system based on CQRS can be done without Event Sourcing. But Event Sourcing has some advantages, that doesn’t come naturally from a system, that just contains the current state, such as getting answers to new questions from a system that is already running. This makes the Event Sourcing concept very interesting. Also, data from a system based on Event Sourcing is quite different: current state is not persisted in the data store. Instead, all the events that occurred in the system lifetime are saved, from which current state of any domain object can be extracted!

With many years of experience with development of n-layered systems, Björn and I agreed that it was about time to get our hands dirty with CQRS and Event Sourcing. We wanted to gain real life experience, and thereby get a bit of distance to theoretical discussions, some of which where a bit too glorifying, and instead be able to make choices on behalf of our enterprise customers based on real experience. This is the reason behind the overdesign of www.miljoparkering.se – it’s by design.

As of writing this, with version 1.0 of the system, we are aware that this is only the start of our experience with CQRS+EventSourcing. Our professional experience tells us that we need to experience at least (1) an upgrade iteration, as well as at some point (2) facing a previous design choice, that has to be refactored/rectified/expanded. I will blog when we reach those experiences.

When we set out to create www.miljöparkering.se, we wanted it to be a win situation from the very start. That is, even if the site wouldn’t ever gain significant user adoption, our goal was to at least make it a personal win.

One of the things that both Björn and I had wanted to break into was cloud computing. We wanted to gain experience in hosting a web service in the cloud. We also wanted to control and maintain the entire stack of the web service, from web server to database server, to background services.

The inspiration for using Amazon’s cloud services (or, Amazon Web Services (AWS), to be exact) came from talking to Lars Krantz and Thomas Mårtensson, the guys behind www.malmofestivalen.se. During our communication while I was creating the Android application, I got a lot of input on how they did things on the site and got to know their thoughts on how to maintain and scale the site. And as you might have noticed the last two years, that site has run perfectly with high availabilty. 

So, in preparation to developing www.miljoparkering.se I sent Lars some questions, which yielded an answer which I, at first, found rather cryptic. But basically it was just very much in line with one of the toughest parts of getting involved with Amazon’s AWS: you have to understand a huge pile of acronyms, services and entities and how they all relate to each other!

I all honesty I think Amazon AWS has a steep learning curve. Documentation is present, but is huge and overwhelming. Trying to predict costs is almost an intimidating task (although it’s gotten a lot better since the first time I looked through their pricing information some years ago). The detailed sign-up process includes identity validation through phone (very well implemented, though, technically speaking). Once you’re validated, you can log on to your personal web console, a AWS universe full of detailed information. Also, using the AWS SDK for .Net has its quirks, such as initially failing when used with log4net (caused by an unexpected side effect). 

However, for those considering to try out Amazon AWS, I do have some encouragement: True, Amazon AWS is very advanced and can be quite overwhelming. But you can ignore most of it and just focus on the part of AWS, that you initially need. For us it was EC2 (Elastic Computing) servers. After getting a server up and running, we started to look at other services, such as Elastic IP (public IP for the server, hard to get around ;-), firewall setup, and the SES, Simple Email Service, for sending out our notifications.

Although the site itself could fit easily into a normal web hotel, the Amazon server gave us the flexibility and control we needed. And over time, the cryptic mail from Lars turned out to be very useful information, once I had gotten acronyms in place (thanks Lars ;o)

When Björn and I put up our landing page for www.miljoparkering.se we had Google Analytics (GA) in place from the very start.

Our landing page contained two points of user interaction, the sign-up and the contact form, so creating goals based on these actions was obvious to us.

Soon, however, we started getting curious about how much of the information on our landing page the users were seeing and at what point they would start loosing interest and leave. But as our landing page didn’t have sub-pages, we didn’t really have any any obvious data to tell us what the users were doing other than visit the first page. From a GA perspective we were a bit in the blind …

We started thinking about what we could do about this. What we’d really like was a solution based on GA goals which would mean that we could use funnel visualization, a great way to display the users progress and their exit points. However, GA goals and funnels are based on page views and cannot be based on events, so we needed to somehow hack it a bit.

Our solution ended up like this: