Day 3 Tight Coupling? , More abut Exceptions,

Olaoluwa Oke| 22 June 2025

When I first modeled the Room entity, I gave it a field like:

val members: List<.User>


It felt natural. A room has members. Why not just store them there?,But the winter before, I took a design patterns clas and i could intuitively feel something was odd

The Problems


  • MongoDB 16MB limit: Embedding a growing list of users in a single document will eventually hit the cap — especially for active, large rooms.(highly unlikely but hey)
  • Tight Coupling: If a user changes (name, status, etc.), every room document they’re embedded in must also be updated. That’s redundancy + bloated writes + data inconsistency waiting to happen.
  • Flexibility: Storing references (roomId in User) makes membership queries index-friendly and reduces coupling between aggregates.




  • Technical Log — Global Exception Handling

    In a roommate app like Awa, things will go wrong: Now when building a roommate management app like Awa or any other app for that matter , things don’t always go as planned(rarely goes as planned ).
    A user might try to join a room with the wrong code or may try to join a non existent room. Or maybe trying to kick a user that is not in a room out (real). But when these errors happen , we now do not want the server to break down or stop

    Instead of scattering try-catch statements throughout the entire codebase, we implemented a clean and scalable error-handling system using @ControllerAdvice, a powerful Spring Boot annotation that centralizes exception handling across all controllers.

    Why Global Error Handling?

    As the project grows, the number of possible exceptions that can occur will increase. Therefore, to reduce this problem and simplify error management as much as possible, I had to build some certain structures and i had to build a Global Exception handler, This reall just help bubble errors encountered in the Service layer or even any where for that matter , Filters , Bublle it down back to the Exception Handler , , In the Exception Handler , you would have a handle method that handles everytype of exception that you might have , and you would annotate that with ... quite directly @ExceptionHandler annotation You would make each class of these error types ( that end up being parameters in the ExceptionHandler method) and make them extenc what type of error they are , Usually , Runtime Exceptions

    And also to format errors better for front end guys (my guy)

    0