GP »Event-Driven Architecture in an eCommerce Application« (GP Event-Driven Architecture in ECommerce (WS23)), WS23
In this project, an eCommerce application is to be implemented using a microservice architecture. In order to achieve the highest possible resilience and decoupling, the services should communicate asynchronously with each other based on events. The goal is to explore the asynchronous pattern, overcome “mental model”, and look for good programming practices along the way.
- event-driven architecture, domain-driven design, microservice, eCommerce, software architecture
- Study Program and Module Description
Master Digital Sciences (specialization Software Architecture)
(see also module description in the study program web site)
- Begin/End and Scheduling
Beginning of October - End of Feb 2024. Organized as an agile project with sprints every 2 weeks. Workload depends on the type of project, will be clarified at kickoff.
- The module takes place in a hybrid format. Please refer to the respective time slot or workshop day (see below on this page), to check if it is online or in presence. If there are no details given on this page, please check the other communication channels (e.g. Discord).
1708 (Building LC4 (library building). Room 1708 is our lab office space, with enough room for small workshops. However, the room is only accessible with by transponder. Thereore, please be at the door left of the library entrance (where you see the label "Kriminalkommissariat", since the Gummersbach police criminal investigation unit is our office neighbour :-). I will fetch you there. Call me (+49 176 8072 2689) or a fellow student by mobile phone in case you should run late), see also
Innovation Hub (Building LC7, the building to the right of the passage to Gummersbach station. The Innovation Hub is not not open to the public. However, the main entrance door is open during office hours. Come up to the second floor and ring the bell there. Please call me (+49 176 8072 2689) or a fellow student by cell phone if no one answers), see also
Video conference link:
- Discord Server for fast Communication
Discord has been proven as a very effective platform for information sharing, discussions, and consultations. Therefore, please join the ArchiLab Discord Server at
Navigate to channel
and click on
Then you see all channel(s) relevant for this module.
When making decisions within a software architecture, there is no right or wrong,
there are only trade-offs. This also applies to the communication between microservices.
In a previous project in the Coding Excellence (CEX) module, an attempt was made to find
out what are the trade-offs between synchronous and asynchronous communication, based on
events, between services using the microservice architecture of an eCommerce store.
As it turns out, it’s noticeably difficult to switch from a synchronous to an event-based
architectural style. It seems that our “software education” is preparing us to think in
a synchronous request / reply pattern. When switching to an asynchronous implementation,
this mental model needs to be overcome, or else we’ll implement a synchronous communication
pattern using asynchronous technology - and therefore will not work truly event-based.
The story so far can be examined in a
paper written in the module CEX.
An eCommerce application is to be implemented using a microservice architecture.
In order to achieve the highest possible resilience and decoupling, the services should
communicate asynchronously with each other based on events. Beside the event-driven
service architecture, the project is focusing on
- asynchronous test concepts (Test driven design, TDD)
- hosting / dev-ops approach (CI / CD), and
- security aspects (https/encryption, authentication).
- The goal is to explore the asynchronous pattern, overcome “mental model”, and
look for good programming practices along the way. There should be even more unit tests
that in a traditional test pyramid and even less integration tests. This is because
in async/events, there is a larger proportion of business logic expressed as pure functions,
The “ops” part of the project is explicitly part of the implementation, trying for a true
“DevOps” approach where the development team also tackles ops architecture and implementation.
The following outcomes should be delivered by the project:
- MVP with robust, near-production-level code
- A delivery pipeline able to deploy the MVP to a laboratory environment, from day one
- Documentation with an assessment / reflection of the architectural patterns used
If there is enough time, the following aspects would be an interesting extension:
- Minimal observability capacity for microservices participating to the product
- Minimal identity and access management for microservices participating to the product
- Operational experimental setup able to demonstrate the resilience of the product under several service disruption scenarios
- Operational experimental setup able to demonstrate the resilience of the product under heavy payloads
- Understanding what a event based communication truly is
- Knowledge about microservice architectures
- Tradeoff for asynchronous communication between microservices with event-based message brokers
- Testing in a asynchronous environment (e.g. unit tests, integration tests, end2end, …)
- Knowledge in the Dev-Ops approach
- Learning from practitioners (Michaël and Wolf from ThoughtWorks)
Requirements for participating
- Solid coding experience in Java, .NET Core, or any other language suitable to implemented a microservice
- Interest in architecture patterns and good practices in coding
- Frontend or backend experience
- Experience with an event broker (Kafka) helps, but is not a must
External Project Partner
ThoughtWorks, with Wolf Schlegel and Michaël Le Barbier both working for thoughtworks.com
The grading for this Guided Project will follow the
general grading scheme for Guided Projects outlined here.