About three months ago, I took part in a challenge that got me really excited.
That’s why I decided to share how the development process went, the technical choices I made, and some lessons I learned along the way.

Github: Dwitch

I’m open to suggestions for improvement.

⚠️ Spoiler: the project is just getting started — there's still a lot to be developed.
What I'm sharing here is only what was built during a 3-to-4-day challenge.

THE CHALLENGE

The goal was to create a complete application:

• Frontend and backend
• Authentication
• Data persistence
• Observability
• Messaging

All of this in a distributed architecture, with proper project documentation.

Starting point

The first step was to decide what kind of application to build.
Since I already had an interest in exploring the topic, I chose to create a live streaming application — even knowing that the available time wouldn’t allow me to implement all the real-world features of such a system.

Architecture

The next step was to define the architecture.
I started by thinking about the functionalities the system should have, organizing them into modules, and aligning everything with the challenge’s requirements.

In the diagram, we have a PostgreSQL database centralizing the system’s data and four main modules:

• Auth – authentication
• Channels – channel CRUD
• User – user CRUD
• Broadcast – stream communication

At this initial stage, I chose to simulate real-time communication using messaging — which is quite different from actual live streaming — but it fit the scope and time constraints of the challenge.

About the modules

The modules were implemented with Fastify, whose syntax is very familiar to anyone who has worked with Express.
For messaging, I used RabbitMQ.

Data modeling

After visualizing the application and its architecture, I moved on to database modeling.

In this model, I defined:

• The relationship between users and channels
• The relationship between channels and streams
• The link between streams and their respective logs

This structure makes it possible to track the status of each stream and keep a history of changes.

Tools used in this stage

• Diagrams: Draw.io
• APIs: Fastify
• Messaging: RabbitMQ
• Protocols: HTTP and WebSocket

💡 Next steps: In the next post, I’ll detail how I implemented each module and how I set up communication between them.

If you have any questions or suggestions for improvement, feel free to leave them in the comments!