How Changing Requirements Shape the Infrastructure of a Software Project

🎬 Introduction

Since few weeks ago I'm learning about AWS SAM so I decided to create a small project to put in practice what I've been learning.

The project is a wallet app with features we all know:

• Register incomes and outcomes.
• Categorize the incomes and outcomes.
• Label the incomes and outcomes

An important requirement of this dummy wallet app was to allow users to create and manage their own categories for tracking incomes and outcomes. But, these categories needed to be private to each user meaning that a category created by one user could not be shared with another.

💪 Hands To Work

So I started designing the DB using this cool tool. The project has 2 tables, users and categories . The user can create many categories as he wants so the first approach I took was creating a third table, a union table to store user_id and category_id.
With this solution the users are able to create x numbers of categories and we can see assign the category to the user.

Example:

⚠️The problem

Technically, this approach works but something smells weird here. While it correctly assigns categories and users, the current design allows to assign a category created by User A to User B.
For example if user Alejandro creates the "Health" category, this category can be assigned to user Edith by simply creating the record in user_categories table. But the requirement is clear: A user can create as many categories as they want, but these categories must not be shared. Categories created by a specific user should remain tied to that user only.

🤓 The Solution

Although we can enforce this rule both on the backend and frontend, it’s generally a good practice to align all components with the project’s core requirements to maintain clarity and consistency.

So at the end, I've changed the design to this:

This aligns with the given requirement and reduces the complexity of the database.

🧠 Conclusions

I know this is a very basic example but its clear and concise. While coding is a crucial (and funny) part of the job, a software engineer’s role is to think critically about the design choices, taking into account factors like maintainability, security, and scalability.