Smart Parking Guidance Using Kafka, Flink, and Spring Boot

Introduction

The article explains why a smart‑parking guidance system is far more complex than simply displaying empty spots. It must handle a high‑frequency event stream, sensor noise, strict latency, and end‑to‑end consistency across multiple services.

Business Challenges and Goals

Key pain points include high event volume (35,000 events/s), sensor jitter, duplicate reports, and the need for sub‑second end‑to‑end latency (P95 < 800 ms) with >99.9 % accuracy. The system aims to achieve real‑time state calculation, fault‑tolerant ingestion, and production‑grade operability.

Overall Architecture

The solution is split into five domains: device gateway, event bus, real‑time computation, online service, and analytics. Data flows from IoT devices → Spring Boot gateway → Kafka → Flink → Redis / PostgreSQL for fast queries and durable storage, with ClickHouse for historical analysis.

Technology Selection

Kafka : high‑throughput ordered writes, built‑in retention for replay, and exactly‑once support via the Flink connector.

Flink : stateful stream processing, event‑time semantics, checkpointing, and keyed state for de‑duplication and debouncing.

Spring Boot : lightweight gateway and API services, easy integration with Kafka, Redis, and PostgreSQL.

Event and State Modeling

Events are represented by SensorIngressEvent (fields such as deviceId, eventTime, status, etc.). Flink converts these into ParkingEvent objects, then into SpaceStateSnapshot which carries the current status, previous status, version, and fault flag.

public class SensorIngressEvent {
    @NotBlank private String deviceId;
    @NotBlank private String deviceType;
    @NotBlank private String parkingLotId;
    @NotBlank private String floorNo;
    @NotBlank private String zoneNo;
    @NotBlank private String spaceId;
    @NotBlank private String status;
    @NotNull  private Long eventTime;
    private Long receiveTime;
    private Double confidence;
    private String source;
    private String traceId;
    private Map<String, Object> ext;
}

Flink Job Configuration

The job uses streaming mode with a parallelism of 12, checkpoint interval 30 s, exactly‑once semantics, and unaligned checkpoints to survive back‑pressure spikes.

public static StreamExecutionEnvironment create() {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.setRuntimeMode(RuntimeExecutionMode.STREAMING);
    env.setParallelism(12);
    env.enableCheckpointing(30_000, CheckpointingMode.EXACTLY_ONCE);
    env.getCheckpointConfig().setMinPauseBetweenCheckpoints(15_000);
    env.getCheckpointConfig().setCheckpointTimeout(120_000);
    env.getCheckpointConfig().enableUnalignedCheckpoints();
    return env;
}

State Machine for Parking Spots

The SpaceStateProcessFunction maintains a ValueState<SpaceStateSnapshot> per spaceId. It discards out‑of‑order events, suppresses rapid status flips within a 3‑second debounce window, and emits a new snapshot only when the status truly changes.

public void processElement(ParkingEvent event, Context ctx, Collector<SpaceStateSnapshot> out) {
    SpaceStateSnapshot previous = currentState.value();
    if (previous != null && event.getEventTime() < previous.getLastEventTime()) return;
    boolean sameStatus = previous != null && previous.getCurrentStatus().equals(event.getReportedStatus());
    long interval = event.getEventTime() - (previous != null ? previous.getLastEventTime() : 0);
    if (!sameStatus && interval < 3_000) return; // debounce
    SpaceStateSnapshot next = buildSnapshot(previous, event, !sameStatus);
    currentState.update(next);
    if (next.isChanged()) out.collect(next);
}

Exactly‑Once End‑to‑End Guarantees

Checkpointing guarantees that the Kafka offset and Flink state are consistent. For external sinks, the article stresses versioned upserts: Redis stores the latest snapshot with a version field, while PostgreSQL uses

INSERT … ON CONFLICT … WHERE version < EXCLUDED.version

to prevent stale writes.

INSERT INTO parking_space_status (..., version, ...) VALUES (..., :version, ...)
ON CONFLICT (space_id) DO UPDATE SET ...
WHERE parking_space_status.version < EXCLUDED.version;

Sink Design

Redis : per‑space hash ( parking:space:{spaceId}) and per‑zone aggregates ( parking:zone:{lot}:{floor}:{zone}) with TTL (24 h) to keep hot data fast.

PostgreSQL : authoritative state table with primary key space_id and version‑based UPSERT for durability.

ClickHouse : stores aggregated historical snapshots for analytics (occupancy trends, peak detection).

Service Layer (Spring Boot)

The guidance API reads from Redis first, falls back to PostgreSQL when needed, and computes a recommendation score that combines free spaces, distance to entry, congestion, and historical turnover.

score = freeWeight * freeSpaces
        - distanceWeight * distanceFromEntry
        - congestionWeight * queueLevel
        + turnoverWeight * historicalTurnoverRate;

WebSocket pushes updates to LED screens and mobile apps.

Scalability and High‑Concurrency Design

Gateway instances are stateless and horizontally scalable. Kafka partitions are aligned with parkingLotId:spaceId keys to avoid hotspoting. Flink parallelism matches or exceeds partition count. Read path is 90 % served from Redis, with a Caffeine second‑level cache for hot queries.

Observability, Monitoring, and Alerting

Key metrics include Kafka consumer lag, Flink checkpoint latency, Redis memory usage, and API P99 latency. Alert thresholds are defined (e.g., consumer lag > 100 k for 5 min, checkpoint failures ≥ 3 in 10 min).

Typical Production Issues and Remedies

Flink back‑pressure – increase TaskManager slots, batch sink writes, add Kafka partitions.

Redis memory bloat – enforce TTL, store only current snapshots, periodic zombie‑key cleanup.

Data inconsistency – versioned writes, PostgreSQL UPSERT with version check, bounded out‑of‑order handling.

API snowball during peaks – two‑level caching, pre‑aggregated zone data, circuit‑breaker fallback to last known snapshot.

Containerization and Kubernetes Deployment

All services are packaged as Docker images and deployed via Kubernetes Deployments with HPA based on CPU utilization. Flink runs in session mode on K8s with RocksDB state backend stored in S3. Prometheus/Grafana/Loki provide metrics, dashboards, and log aggregation.

Conclusion

The guide demonstrates that a smart‑parking guidance system is essentially a real‑time state computation platform. By combining Kafka for reliable messaging, Flink for deterministic stateful processing, and Spring Boot for ingestion and API services, the architecture satisfies sub‑second latency, high accuracy, and production‑grade reliability.