System Architecture

I built this pipeline to understand how cities handle massive amounts of sensor data in real-time. Think of it as the backend for those smart traffic systems that adjust lights based on traffic flow, or emergency systems that route ambulances through the fastest paths.

What It Does

The pipeline ingests data from multiple sources:

  • Vehicle data (speed, location, engine diagnostics)
  • GPS tracking from city vehicles
  • Weather sensor readings
  • Traffic camera metadata
  • Emergency system alerts

All this data flows through Kafka, gets processed by Spark, and lands in AWS for analysis. Pretty standard streaming architecture, but the interesting part was handling different data types and rates simultaneously.

How I Built It

Started with Docker Compose to run everything locally. This was key - nobody wants to spin up a whole AWS cluster just to test something.

The main components:

  • Kafka cluster: 3 brokers with Zookeeper for coordination
  • Spark streaming: Processing engine that does the heavy lifting
  • Python scripts: Generate realistic data and handle specific processing logic
  • AWS stack: S3 for storage, Glue for cataloging, Athena for queries

The Data Flow

  1. Python producers generate data mimicking real sensors - vehicles moving through the city, weather changing, occasional emergency events
  2. Kafka ingests everything, routing to different topics based on data type
  3. Spark reads from Kafka, does windowed aggregations (5-minute traffic summaries, hourly weather patterns)
  4. Processed data goes to S3, partitioned by date/hour for efficient querying
  5. Glue crawlers keep the schema updated as new data arrives
  6. Analysts can query everything through Athena using regular SQL

Interesting Challenges

Different data rates: Weather updates every minute, vehicles send data every second, cameras stream continuously. Had to tune Kafka partitions and consumer groups to handle this without one slow source blocking others.

State management: Tracking vehicles across zones required maintaining state in Spark. Used mapWithState for efficiency - way better than updateStateByKey.

Schema evolution: Sensors get upgraded, new fields appear. Built the pipeline to handle schema changes gracefully instead of breaking.

Cost optimization: S3 gets expensive fast. Implemented smart partitioning and lifecycle rules to move old data to cheaper storage.

What I Learned

  • Kafka’s partition strategy matters more than you think
  • Spark Streaming’s micro-batches are actually pretty clever for this use case
  • Docker Compose is amazing for local development of distributed systems
  • AWS Glue is convenient but can get pricey if you’re not careful with crawler schedules

Real-World Use

This architecture works for any multi-source streaming scenario:

  • Fleet management systems
  • Industrial IoT monitoring
  • Real-time analytics platforms
  • Event-driven microservices

The patterns are the same whether you’re processing city sensors or e-commerce clickstreams.

Code and setup instructions: https://github.com/priyam-choksi/City-Real-Time-Streaming-Data-Pipeline