Events Exercise

Introduction

The events exercise represents a simplified version of the event-sourcing concepts that we use internally at Utility Warehouse. At UW we consume streams of events (from Apache Kafka), and write changes from said events into a database (a projection) to build a view of the "current state" of our data, instead of its time-series representation.

For example, an event stream might contain a number of EmailChangedEvents to describe how an account's associated email has changed over time. However, our microservice may only be interested in the user's current email address. If we update our database every time that we encounter an event of this type, once we have processed the full event stream the database should contain the current email address for a given account and will continue to update for the future.

Guidance / Rules

1. Don't stress! This is a pairing exercise and you'll have friendly UW engineers to help nudge you in the right direction and offer advice if you need it.
2. We're not looking for a perfect solution, instead, we're looking to understand more about your thought process, how you approach problem solving, and how you choose to structure your solution.
3. This challenge is designed to be flexible and somewhat open-ended. You may not finish it all in the time that we have, and you shouldn't feel bad about that. Do what you can, and don't be upset if we don't get through the entire challenge.
4. Please do your best to vocalise your thought process. We're very interested in what you're thinking when you are designing and implementing your solution. We will also want you to screen-share your editor so that we can see your solution.
5. Feel free to google, use references, and anything else you need to assist with your solution. We appreciate that engineers aren't walking encyclopaedias of code and sometimes we need to jog our memories. Treat the exercise as you would a typical piece of work.

Challenge

At UW we write our data projections into relational databases, search indexes, or other forms of longer-term data stores. To simplify this challenge, we will instead write code to create an "in-memory" (for example a Map or other collection) projection of account data from a stream of events that describe how a user account changes over time.

With your projection in place, it should contain the current (most up-to-date) ID, full name, email address and number of badges of each type for each of the accounts in our data stream.

Events

Events are modelled in protobuf, but have been compiled into Java classes found within the src/main/java/accounts/ directory for your convenience.

• UserAccountCreatedEvent — Received when an account has been created on our system. It contains only a user ID, a UUID string which acts as a unique identifier for the new account.
• UserAccountUpdatedEvent — Received when the information (name, email) is first set or changed for a given user account identified by the associated user ID. Note that only populated fields should be updated in the projection.
• UserGainedBadgeEvent — A user has gained a badge of a certain colour. Users can have any number of badges of each colour. Accounts are created with zero badges of each colour.
• UserLostBadgeEvent — A user has lost a badge of a certain colour. The number of badges of each type may not fall below zero.

You'll find the event stream code within src/main/java/events/Stream.java. By providing an implementation of the StreamReader interface to the read() method of the Stream class, you'll be able to read events one at a time. For example:

class Reader implements StreamReader {
    @Override
    public void read(Object event) throws Exception {
        // Use the event to update your projection.
    }
}

public class Main {
    public static void main(String[] args) throws Exception {
        Stream stream = new Stream();
        stream.read(new Reader());
    }
}

Badge Status

Accounts are given a particular status based on the number of badges of each type that they hold. Here's a list of the possible badge status values:

• Great — Default status.
• Amazing — 3+ Blue badges.
• Ultimate — 6+ Blue badges and 3+ Red badges.
• Champion — 10+ Blue badges, 5+ Red badges and 1+ Green badge.

Badge status should be included in the account's projection.

Additional Challenges

If you have extra time, or you're looking to continue the challenge in your own time, here are some additional challenges.

1. Consider how you would test the logic that creates your projection. How would you change your implementation to make this possible? Attempt to write some unit/acceptance tests to confirm that your projection logic functions as expected.
2. Build a simple REST API to expose the data in your projection. For example, a simple endpoint that retrieves a JSON payload for a user including name, email and badge status for a given account ID.

Running

Requires Java 17+ and Maven.

mvn compile exec:java