Project case study

Point-of-interest proximity streaming pipeline

Real-time location intelligence that detects when users enter a point-of-interest radius.

Moved location-aware decisioning into the event stream by combining GPS and network-triangulated location signals with point-of-interest context such as retail outlets, offers, and airports.

Flink Kafka Java Geospatial streaming Elastic Stack Influx Airflow

Context

The problem

The product needed to react when a user came near a relevant location such as a retail outlet with an offer or an airport. The location data was not only GPS-driven; it also included network-triangulated signals, which made proximity evaluation a streaming systems problem rather than a simple static lookup.

The pipeline handled real-time customer location signals, including triangulation-driven location beyond GPS alone, and evaluated proximity against known points of interest for downstream offer and action workflows.

System trace

How the work moved through the system

A high-level operating path: where the request starts, how the system shapes it, and how other teams consume the result.

1
Kafka carried customer location events and point-of-interest reference updates into the streaming layer.
2
Flink evaluated proximity against configured points of interest and handled event-time decisioning.
3
Reference data included places such as retail outlets with offers and airports.

Processing mode

Real-time

Proximity decisions needed to happen as location events arrived, not only in offline batches.

Trigger radius

~1 km

The representative business rule was to trigger an action when a user came near a configured point of interest.

Location model

GPS + triangulation

The stream had to account for location signals from both device GPS and network triangulation.

Architecture

System shape

1 Kafka carried customer location events and point-of-interest reference updates into the streaming layer.
2 Flink evaluated proximity against configured points of interest and handled event-time decisioning.
3 Reference data included places such as retail outlets with offers and airports.
4 The location model accounted for GPS and triangulation-based signals, including imperfect precision.
5 Operational stores, monitoring, and scheduled workflows supported downstream actions and maintainability.

Ownership

What I handled

1 Implemented stream processing pieces for point-of-interest proximity decisions.
2 Integrated location events, POI reference data, radius checks, and downstream action paths.
3 Handled location-quality constraints caused by mixing GPS and network-triangulated signals.
4 Balanced real-time behavior with operational visibility and maintainability.

Lessons

What carried forward

1 Real-time location products are as much about signal quality and timing as they are about geospatial math.
2 A useful proximity system needs clear event boundaries, reference data ownership, and operational visibility from the start.

Engineering decisions

Evaluate proximity in the stream

The value depended on reacting while the user was near the location, so batch-only processing would miss the product moment.

Treat location quality as part of the design

Triangulation-driven signals are useful but less precise than clean GPS, so the pipeline needed to tolerate changing confidence and signal quality.

Keep operations visible

Location-trigger systems are difficult to trust when opaque, so monitoring and replay/debug paths matter.

What can be shown

Public evidence without internal names

The internal systems stay private. This section keeps the public parts: my role, system boundaries, technology context, scale, decisions, constraints, and what I learned.

Internal enterprise system High-level architecture Scale signal

Processing mode

Real-time

The product required event-time proximity evaluation rather than only offline audience computation.

Trigger radius

~1 km

The shareable product rule is proximity to a point of interest such as a retail outlet or airport.

Location sources

GPS + triangulation

The pipeline accounted for location signals that were not purely GPS-driven.

Architecture shape

Kafka carries customer location events and point-of-interest reference updates into stream-processing paths.
Flink evaluates proximity between user location and POI boundaries close to event time.
Location signals can come from GPS as well as network triangulation, so the pipeline handles imperfect and changing location quality.
Downstream action paths can trigger relevant offers or notifications when a user enters the target radius.

Responsibilities

Implemented stream-processing and proximity-decisioning components.
Integrated customer location streams, point-of-interest context, radius matching, and downstream action paths.
Handled GPS and triangulation-based location signals in the streaming design.
Kept customer attributes, exact event schemas, offer rules, and partner details out of the site description.

Constraints

Customer attributes, event schemas, offer rules, partner names, and campaign details are confidential.
Proof should show streaming, geospatial, and decisioning shape without exposing user or campaign data.

Supporting context

High-level architecture

High-level POI streaming topology

Can be represented as location events, POI reference data, stream processing, proximity evaluation, action triggers, and operational visibility.

Scale signal

Proximity trigger signal

The case study can state the approximate one-kilometer trigger radius without publishing customer or campaign details.

Related case studies

Continue through related work or return to the full project index.

All projects

Related projects

Continue in the same area

Project index

Flink + Kafka + Backend engineering