Should someone looking for a few nearby arcades first have to download every arcade? With a small initial list, calculating distances in the browser was workable. As Musecat expanded beyond Korea in the second half of this year, downloading everything before selecting nearby places became increasingly difficult to sustain.

Full-list downloads and initial loading

The home page fetched all arcades and calculated the distance to each one. The load grew beyond 200 venues; approaching 300 meant transferring more information that the first screen never used. Separate APIs supplied search and distance-calculation lists, sometimes delivering similar data twice.

Reproduction of Delta using the July 1, 2025 legacy Gamma-Web source with synthetic data. The home screen before the server move. Original English route; the legacy client marked these translations as demonstrations, and some labels and sample data remain Korean.

Keyword search moved to the server last year, but home-page distance calculations still needed the full list. This year, initial loading exceeded three seconds and reached roughly five. For example, a search around Seoul still depended on receiving distant venue information. Adding overseas places would lengthen the preparation for that request further.

flowchart TD
    accTitle: Distance calculation in the browser
    accDescr: The browser downloaded the whole list before calculating distances and ordering nearby places.
    A["Full arcade list"] --> B
    B["Browser download"] --> C
    C["Distance calculation and sorting"] --> D
    D["Display nearby places"]

Distance and search conditions on the server

A nearby search already has a position and conditions. We changed the browser to send those inputs, allowing the server to calculate distance, filter candidates and sort the results. Only places matching the chosen conditions return to the interface.

Changing databases could be considered separately, but it would not remove the full-list dependency by itself. We addressed that dependency first. Just as keyword search sends a query and receives matches, nearby discovery now requests results using a position and conditions.

flowchart TD
    accTitle: Nearby search moves to the server
    accDescr: The browser sends position and conditions, then the server selects and returns results.
    A["Search position and conditions"] --> B
    B["Server distance calculation and filters"] --> C
    C["Sorted relevant results"] --> D
    D["Display results"]

The search position and result scope

The server calculates distances from the search coordinates and orders matching candidates from nearest to farthest. The browser presents the returned results. It no longer needs to receive all records before starting the same calculation itself.

The search position is the reference point for discovery. It may be the current location or a destination the user chooses. For example, distances around a city planned for travel do not describe distance from the user’s present location. Making the reference explicit keeps results understandable; supplying it does not certify an actual visit.

flowchart TD
    accTitle: The cost of moving calculation
    accDescr: Reduce full-list transfers while taking responsibility for server computation and updates.
    A["Remove full-list transfer dependency"] --> B
    B["Receive only necessary results"] --> C
    C["Manage server calculations and data updates"]

Transfer volume and server processing

Displaying a few nearby places no longer requires sending the entire database. As venue coverage grows, the returned data can remain limited to relevant results, with distance, filtering and sorting handled together on the server. Expansion no longer depends on sending an ever larger list to every screen.

The processing cost remains: more requests mean more server work to select candidates and calculate distance. We also need to manage when venue edits appear in results. The first step removes the requirement to download everything; remaining costs will be assessed against actual requests and usage.

Reference: Nearby search and loading structure.