If you want to implement the Kafka ecosystem in practice — Apache Kafka producers and consumers, Kafka Connect (CDC and sinks), and Kafka Streams (real-time aggregations, alerts, dashboards) — this page gives you seven full-domain project ideas.
Each project idea below is one domain (e.g. hospital, ticketing, logistics): you — or your team — design and build a full system in that domain, not a single-service or toy example. That means applying core Kafka (topics, producers, consumers, consumer groups), Kafka Connect (at least one CDC source and, where relevant, a sink such as Elasticsearch), and Kafka Streams (aggregations, windowing, state stores, Interactive Queries or output-topic consumers for dashboards).
Whether you are learning the Kafka ecosystem, running a proof-of-concept, or structuring a training or assignment, these ideas give you concrete, production-style domains to implement end to end.
Full story for non-members | E-Books on Java/Microservices/Springboot Whatsapp Group| Youtube | LinkedIn

Note — In all the projects below React App mentioned as front end client, this is totally optional, you can use any other client like postman or other UI you comfortable with to interact with backend
This story is completed by the video — to be available on codefarm youtube channel before 13th Mar 2026
1. Hospital Management System
Domain: End-to-end hospital flow: patient registration, appointments, admissions, billing, pharmacy, lab results, and notifications. Multiple actors (patient, doctor, admin, pharmacy, lab). The system must support the full lifecycle from registration through discharge and billing.
High-level component diagram

Services (example — group must design equivalent): Patient Service, Appointment Service, Admission/Bed Service, Billing Service, Pharmacy Service, Lab Service, Search/Index Service (e.g. patient or doctor search), Notification Service. At least 5–6 services.
Core Kafka: Event-driven flow: e.g. appointment booked → payment → confirmation; admission → billing → discharge; lab result → notification. Topic design for all domain events; idempotency for payment and status updates. Consumer groups and failure handling (retry or dead-letter) where appropriate.
Kafka Connect: CDC from at least one DB (e.g. patients, appointments, or billing table) to Kafka; Elasticsearch (or similar) sink for searchable index (e.g. patients, doctors, appointments). Document connector configs and topic names.
Kafka Streams: Aggregations (e.g. appointments per day, revenue by department, lab turnaround); alerts (e.g. bed occupancy, pending bills); dashboards via Interactive Queries or consumer of Streams output topics. Document topology and state store names.
Deliverables: HLD/LLD document (same style as e-commerce), topic list, connector config summary, Streams topology description, README. Optional: React UI for key flows (e.g. patient registration, appointment booking, admin dashboard).
2. Ticket Booking Platform (Events / Cinema / Travel)
Domain: Venue/event catalog, search, seat selection, booking, payment, confirmation, cancellation, and notifications. Multiple services for a full booking lifecycle. Actors include customers, venue owners, and admins.
High-level component diagram

Services (example): Venue/Event Service, Search Service, Booking Service, Payment Service, Confirmation/Cancel Service, Notification Service. At least 5–6 services.
Core Kafka: Saga-style: create booking → payment → confirm or cancel; events for booking-created, payment-processed, booking-confirmed/cancelled. Topic design with meaningful keys (e.g. bookingId, venueId); idempotency (e.g. double payment prevention). Consumer groups and error handling.
Kafka Connect: CDC from DB (e.g. venues, events, bookings) to Kafka; Elasticsearch sink for event/venue search. Document connector configs and index mapping.
Kafka Streams: Aggregations (bookings per venue/time window, revenue, cancellation rate); alerts (e.g. high cancellation); dashboards via Interactive Queries or consumer. Document topology and stores.
Deliverables: HLD/LLD, topic list, connector configs, Streams topology, README. Optional: React for browse, book, and admin views.
3. Logistics and Shipment Management
Domain: Shipment creation, warehouse/inventory, routing, delivery tracking, proof of delivery, invoicing, and notifications. Carriers, warehouses, and end customers. Delivery status can be UI-driven (e.g. delivery person marks status) similar to the e-commerce delivery flow.
High-level component diagram

Services (example): Shipment Service, Warehouse/Inventory Service, Routing Service, Delivery Service (with UI-driven status like e-com delivery), Billing/Invoice Service, Notification Service. At least 5–6 services.
Core Kafka: Flow: create shipment → allocate warehouse → route → delivery updates (UI-driven) → invoice. Event-driven status propagation; idempotency for status and invoice updates. Topic design and consumer groups.
Kafka Connect: CDC from shipments/warehouse/invoice tables to Kafka; optional sink for search or analytics. Document connector configs.
Kafka Streams: Aggregations (shipments per route/region, delivery time, invoice amounts); alerts (delays, failures); dashboards. Document topology and state stores.
Deliverables: HLD/LLD, topic list, connector configs, topology, README. Optional: React for create shipment and delivery-person status views.
4. Banking / Payments and Transfers
Domain: Accounts, transfers, payments, statements, fraud/suspicion checks, and notifications. Multi-step flows with strong consistency and exactly-once considerations. Actors: customers, internal ops.
High-level component diagram

Services (example): Account Service, Transfer Service, Payment Service, Statement/Reconciliation Service, Notification Service, optional Search/Index. At least 5–6 services.
Core Kafka: Choreography: transfer initiated → debit/credit → confirm or rollback; payment events; idempotency and exactly-once considerations. Topic design; consumer groups and failure handling.
Kafka Connect: CDC from accounts/transactions DB to Kafka; optional sink for reporting or search. Document connector configs.
Kafka Streams: Aggregations (volume by account/time, success/failure rates); alerts (e.g. failure spike, threshold); dashboards. Document topology and stores.
Deliverables: HLD/LLD, topic list, connector configs, topology, README. Optional: React for transfer and statement views.
5. Education / Course Enrollment and Learning
Domain: Course catalog, search, enrollment, payments, assignments/grades, certificates, and notifications. Students, instructors, admin. Full lifecycle from course discovery to certificate issuance.
High-level component diagram

Services (example): Course Service, Search/Index Service, Enrollment Service, Payment Service, Grade/Assignment Service, Certificate Service, Notification Service. At least 5–6 services.
Core Kafka: Flow: enroll → payment → enrollment confirmed; grade submitted → certificate eligible. Event-driven updates; idempotency for enrollment and payment. Topic design and consumer groups.
Kafka Connect: CDC from courses, enrollments, or grades DB to Kafka; Elasticsearch sink for course search. Document connector configs and index.
Kafka Streams: Aggregations (enrollments per course, revenue, completion rate); alerts; dashboards. Document topology and stores.
Deliverables: HLD/LLD, topic list, connector configs, topology, README. Optional: React for catalog, enroll, and instructor views.
6. Retail / Store and Inventory (Alternative to e-commerce)
Domain: Multi-store retail: store and product catalog, inventory across stores, stock transfers, POS/sales, replenishment, and reporting. Stores, warehouse, admin. Focus on inventory and cross-store operations rather than a single customer checkout flow.
High-level component diagram

Services (example): Store/Product Service, Inventory Service, Transfer Service, POS/Sales Service, Replenishment Service, Search/Report Service, Notification Service. At least 5–6 services.
Core Kafka: Events: sale → inventory update; low stock → replenishment; transfer requested → confirmed. Saga where applicable; idempotency. Topic design and consumer groups.
Kafka Connect: CDC from products, inventory, or sales tables to Kafka; sink for search or analytics. Document connector configs.
Kafka Streams: Aggregations (sales by store/time, inventory levels, transfer volumes); alerts (low stock, discrepancies); dashboards. Document topology and stores.
Deliverables: HLD/LLD, topic list, connector configs, topology, README. Optional: React for POS and admin views.
7. Subscription / Billing and Usage
Domain: Plans, subscriptions, usage metering, billing, invoices, dunning, and notifications. SaaS-style subscription lifecycle. Multiple services for plan management, usage collection, billing cycles, and failure handling.
High-level component diagram

Services (example): Plan Service, Subscription Service, Usage/Metering Service, Billing Service, Invoice Service, Dunning/Alert Service, Notification Service. At least 5–6 services.
Core Kafka: Flow: subscribe → first payment → active; usage events → billing cycle → invoice; payment failed → dunning. Choreography and idempotency. Topic design; consumer groups.
Kafka Connect: CDC from subscriptions, usage, or invoices to Kafka; optional sink for reporting. Document connector configs.
Kafka Streams: Aggregations (revenue by plan, churn, usage trends); alerts (failed payments, usage spikes); dashboards. Document topology and stores.
Deliverables: HLD/LLD, topic list, connector configs, topology, README. Optional: React for plan selection and billing views.
Conclusion
These seven Kafka ecosystem project ideas cover different domains (healthcare, ticketing, logistics, banking, education, retail, subscription) while reusing the same stack:
- Apache Kafka for event streaming,
- Kafka Connect for CDC and search indexing, and
- Kafka Streams for real-time analytics and dashboards.
Picking one domain and implementing it end to end — with proper topic design, saga or choreography where needed, idempotency, and Streams topologies — is a strong way to learn or validate the Kafka ecosystem.
Use the e-commerce HLD/LLD as your reference for depth and deliverables; then choose a domain above and build.
Each project gives you hands-on experience with producers, consumers, Connect connectors, and Streams in a single, coherent system.
— — -
Liked this deep dive story? If Yes Please 👏 Clap(50) | 📤 Share | 🔔 Follow
=======
Below is a collection of all related stories in one place