The Calendar We Designed for KakaoTalk Booking (opens in new tab)
KakaoTalk Reservation built a time-block calendar to help sellers understand inventory and bookings more easily than with a card list. The main challenge was arranging bookings with different start times and durations so that they remain readable and use space efficiently. The solution combines sorting rules, graph-based layout calculation, DFS, and additional expansion logic for edge cases. ## Product Requirements - The calendar is designed for the seller-facing reservation management center. - Each time slot can contain up to 10 bookings. - A booking can last from one to six hours. - Booking blocks should be displayed as clearly as possible without leaving unnecessary gaps. - The input data provides booking start and end times, while the frontend must calculate the visual layout. ## Booking Placement Rules - **Sort by earliest start time** - Earlier bookings are placed first to match the seller’s natural workflow. - This also supports the typical visual scanning order from the upper-left toward the lower-right. - **For bookings starting at the same time, sort by longest duration** - Longer bookings can block shorter bookings from expanding. - Placing them first gives them enough space and allows later bookings to occupy the remaining areas more effectively. ## Graph-Based Expansion - The bookings are modeled as nodes in a graph. - Each node stores relationships with preceding and following overlapping bookings. - A depth-first search calculates: - Each node’s depth, representing its horizontal position. - The maximum distance to the final booking in its connected path. - These values are used to calculate: - `left`: the node’s horizontal starting position. - `width`: how far the booking can expand across available space. - Nodes at the far-left edge of the graph are processed first, allowing the bookings to fill the calendar while respecting overlaps. ## Handling Layout Exceptions - The initial graph and DFS calculation did not always fill all available space. - Problems occurred when: - Multiple root nodes existed. - An upper root node had a longer path than a lower root node. - Connected nodes were constrained by earlier width calculations. - The implementation searches for unused gaps between neighboring nodes. - When multiple gaps exist, connected nodes are expanded by the smallest available amount needed to close the gaps. - A gap is detected when the next node’s `left` position is greater than the current node’s `left + width`. ## Lessons from the Implementation - A calendar that appears visually simple can require substantial algorithmic design. - Frontend developers are responsible not only for rendering data, but also for deciding how that data should be presented to users. - The calendar is treated as an evolving implementation that will be refined as new bugs, data patterns, and better algorithms are discovered. The practical approach is to begin with clear sorting rules, represent overlapping bookings as a graph, use DFS to determine layout constraints, and add targeted post-processing for unused space and edge cases.