Streamline Blacklist Handling: Add User Status To Reservations

In the ever-evolving world of reservation systems, managing user access and preventing abuse is paramount. Our recent focus has been on refining how we handle blacklisted users, ensuring a smoother experience for both administrators and genuine customers. Previously, our system had a stringent approach: if a user was identified as blacklisted during the payment confirmation stage, their reservation would be automatically rejected and refunded. While this approach aimed for security, it sometimes led to friction and manual intervention. We've listened to feedback and are excited to announce a change: instead of automatically rejecting reservations, we will now simply indicate the user's blacklisted status within the reservation details. This allows for more nuanced management and a better user experience.

Moving Beyond Automatic Rejection: A New Era for Blacklist Management

Previously, our system, as detailed in PR #53, was configured to automatically reject and refund reservations for blacklisted users once payment was confirmed. This was a direct implementation of a security-first policy. However, we've recognized that a more flexible approach can offer significant benefits. The core of this update is to shift from an active rejection mechanism to a passive indicator. This means that when a user is identified as blacklisted, the system will no longer halt the reservation process entirely. Instead, it will flag the reservation so that administrators or the system itself can be aware of the user's status. This change is designed to provide greater visibility and control, enabling more informed decisions without the immediate disruption of an automatic rejection. The background for this shift stems from updated requirements that prioritize displaying blacklist information rather than enforcing an immediate ban at the point of payment confirmation. This allows for scenarios where, for example, a user might be temporarily blacklisted, or where the decision to take further action rests with a human administrator.

Key Requirements for Enhanced Blacklist Visibility

To implement this new, more user-friendly approach to blacklist management, we've outlined two primary requirements. The first is to remove the automatic rejection logic that was previously in place. This involves modifying or completely removing the ReservationConfirmedEventHandler, which was responsible for triggering the automatic rejection and refund process. By eliminating this handler, we ensure that the system no longer intervenes directly to cancel reservations based solely on blacklist status at the point of confirmation. The second, and equally crucial, requirement is to introduce an isBlackUser field into our reservation data. This new field will provide clear and immediate information about a user's blacklisted status whenever reservation details are queried. We've considered two options for implementing this isBlackUser field, each with its own set of advantages and considerations.

Option A: Dynamic Calculation - Our Recommended Path

Option A proposes adding the isBlackUser field to our response Data Transfer Objects (DTOs) for reservation lookups. The key advantage here is that the blacklist status will be dynamically calculated at the time of the query. This means that our ReservationEntity in the database will remain unchanged, simplifying data management and avoiding potential synchronization issues. When a reservation is requested, our Service Layer will perform a check using the BlackListRepository.existsByBlackListKey_PlaceIdAndBlackListKey_UserIdAndExpiredAtAfter method. This ensures that the isBlackUser flag is always up-to-date, reflecting the current status of the user in the blacklist at that precise moment. This approach is highly recommended because it offers the best balance of real-time accuracy and minimal impact on existing database structures. It's a cleaner, more maintainable solution that directly addresses the requirement of providing current blacklist information without altering core data models.

Option B: Database Storage - An Alternative Approach

Option B suggests a different path: adding the isBlackUser field directly to the ReservationEntity in the database. In this scenario, the blacklist check would occur when a reservation is created or updated. The isBlackUser flag would then be stored alongside the reservation data. While this might seem straightforward, it introduces potential complexities. The primary concern with Option B is the risk of synchronization issues. If a user's blacklist status changes after a reservation has been made and their status recorded, the stored isBlackUser field in the reservation might become outdated. Keeping this flag consistent across all relevant reservations would require additional logic to handle updates to the blacklist, potentially involving background jobs or event listeners. This could lead to a more intricate system to manage and maintain, making Option A, with its dynamic, on-demand calculation, a generally more robust and less error-prone solution for ensuring data consistency and accuracy.

Detailed Implementation Steps (Following Option A)

To bring our enhanced blacklist handling to life, we'll follow the proposed Option A, focusing on dynamic calculation. This approach ensures that our system remains agile and that the blacklist status is always current. The implementation will span across different layers of our application, ensuring a comprehensive integration.

Application Layer Enhancements

Within the Application Layer, our primary focus is on how reservation data is presented and processed. First, we will add the isBlackUser boolean field to the reservation query response DTO. This makes the blacklist status readily available to any service or frontend consuming reservation information. Subsequently, we will integrate the blacklist checking logic directly into the reservation query service. This involves leveraging the BlackListRepository.existsByBlackListKey_PlaceIdAndBlackListKey_UserIdAndExpiredAtAfter method. This method efficiently checks if a user, associated with a specific place and user ID, exists in the blacklist and if their ban period has not yet expired, using the current date and time (LocalDateTime.now()) as the benchmark. This ensures that the isBlackUser flag is determined dynamically each time a reservation is queried, providing the most accurate and up-to-date information.

Adapter Layer Adjustments

The Adapter Layer is where our application interacts with external systems and event queues. For this update, a key adjustment will be the removal or significant modification of the ReservationConfirmedEventHandler. If this handler contains logic solely for automatic rejection and refunding, it will be removed entirely. If it serves other purposes, its blacklist-specific rejection logic will be pruned. Additionally, we may optionally remove the Kafka Consumer listener for reservation-confirmed events, but only if the sole purpose of that listener was to trigger the now-removed rejection logic. This cleanup ensures that no residual code attempts to perform the old, automatic rejection process, thereby completing the transition to our new, indicator-based system. By making these adjustments, we streamline our event handling and ensure that the system behaves as intended, reflecting the updated requirements for managing blacklist statuses.

Illustrative Code Snippets

To make these changes tangible, let's look at some simplified code examples illustrating Option A. In the DTO definition, the isBlackUser field is a simple boolean addition:

// DTO Example
public record ReservationResponse(
    Long reservationId,
    Long placeId,
    Long userId,
    ReservationStatus status,
    boolean isBlackUser,  // Newly added field
    // ... other fields
) {}

In the Service layer, the isBlackUser flag is determined during the retrieval process:

// Service Example
public ReservationResponse getReservation(Long reservationId) {
    ReservationEntity reservation = repository.findById(reservationId)...;
    
    // Dynamically check blacklist status
    boolean isBlackUser = blackListRepository
        .existsByBlackListKey_PlaceIdAndBlackListKey_UserIdAndExpiredAtAfter(
            reservation.getPlaceId(),
            reservation.getUserId(),
            LocalDateTime.now()
        );
    
    // Construct and return the response with the new field
    return new ReservationResponse(..., isBlackUser, ...);
}

These examples demonstrate how seamlessly the isBlackUser field can be integrated into existing structures, providing immediate visibility into a user's blacklist status without altering the core reservation data.

Important Considerations for Performance and Consistency

As we implement these changes, it's crucial to keep a few key considerations in mind to ensure our system remains efficient and reliable. The most significant aspect to address is performance, particularly concerning the blacklist checks. Since Option A involves a database lookup for the blacklist status every time a reservation is queried, there's a potential for performance degradation, especially under heavy load. To mitigate this, we should seriously consider implementing caching mechanisms, such as using Redis. Caching frequently accessed blacklist data can drastically reduce database read operations and speed up response times. Furthermore, for scenarios involving batch retrieval of reservations, optimizing the query for blacklist status becomes even more critical. We might explore techniques like fetching blacklist statuses for multiple users in a single query or pre-fetching statuses if possible.

Another vital consideration is data consistency. While Option A's dynamic checking inherently provides near real-time accuracy, we must ensure that any updates to the blacklist are reflected promptly. If a user is added to or removed from the blacklist, the system should ideally reflect this change without significant delay. This ties back to efficient querying and potentially a well-designed caching strategy. By proactively addressing these performance and consistency points, we can ensure that our refined blacklist handling not only meets the new requirements but also maintains the high performance and reliability our users expect. These proactive measures are essential for a robust and scalable system.

Related Technical Discussions

This update is closely related to ongoing efforts in improving our system's integrity and user management. It builds upon previous discussions and developments, specifically related to issue #51, which likely touched upon user management or security protocols. Furthermore, this current implementation is based on the foundation laid by PR #53, which introduced the initial blacklist handling logic. By referencing these related issues and pull requests, we ensure that this change is integrated cohesively within the broader development roadmap and benefits from the lessons learned in prior work.

For further insights into best practices for system design and database management, you can explore resources like Martin Fowler's website, a renowned authority in software development.