CLAPOS
Event-driven microservices platform for film production with 10+ independent services and real-time workflow synchronization via Kafka.
Architect & Lead
Nov 2025 - Present
beta
2025
IDENTIFYING THE
BOTTLENECK.
Context & Pain
Film production involves vendor booking, talent scheduling, location coordination, and equipment allocation—each typically managed in separate tools.
"Departments work in silos. Vendor updates don't sync to scheduling. No unified workflow. Information scattered across spreadsheets and email."
The Challenge
How to build a single system where 10+ independent workflows stay synchronized without tight coupling?
The Insight
"The core problem isn't features—it's orchestration. Services must operate independently while reacting instantly to changes."
ENGINEERING FOR
SCALE & SPEED.
System Architecture
Event-driven microservices with Kafka as the central nervous system—services emit events, others listen and react.
Microservices over Monolith
Why split into independent services instead of one codebase?
Why:Each film workflow (vendors, talent, locations, crew) has independent scaling needs. Monolith becomes a bottleneck when one service gets hammered.
Kafka Event Streaming
Why event-driven instead of REST calls?
Why:Services don't call each other directly. Kafka provides durability (events persist), replay (recover from failures), and natural decoupling.
MongoDB per Service
Why isolated databases instead of a shared one?
Why:Data isolation allows each service to scale independently and own its schema. Prevents cascading failures.
Tech Stack
Key Benefits
- Highly scalable architecture
- Real-time data processing
- Automated anomaly detection
- Optimized query performance
MEASURABLE
IMPACT.
Services Built
0
10+ independent services
Architecture Type
Monolith planned
Event-driven (active)
Frontend Status
Not started
Production-ready on Vercel
Adoption & Reliability
Frontend live
In active development
Backend infrastructure currently building
The Learning
"Event-driven architecture handles workflow complexity better than REST coupling. Infrastructure complexity is a real tax—observability matters from day 1."
OVERCOMING
COMPLEXITY.
Service Decoupling
Initial design had services calling each other directly—classic tight coupling.
Switched to pure event-driven: services emit events to Kafka, others listen. No direct dependencies.
True decoupling requires rethinking communication patterns entirely.
Eventual Consistency
With event-driven systems, data isn't immediately consistent everywhere. What if a service crashes mid-stream?
Kafka event log is the source of truth. Services replay events from the log on recovery. Nothing lost.
Distributed systems trade immediate consistency for resilience. That's the right trade.
TECHNICAL
DETAILS.
Event-Driven Communication Pattern
How independent services stay synchronized without calling each other.
Vendor Service → (REST call) Audition API → (REST call) Schedule API → Tight coupling, cascading failuresVendor emits "vendor.created" → Kafka topic → Audition service listens → Schedule service listens → All react independentlyFINAL REFLECTIONS.
"Architecture scales before infrastructure. Event-driven systems add complexity, but they handle distributed workflows elegantly."
If I were building this again
Implement event sourcing from day 1 (full audit trail)
Plan Kubernetes deployment before coding
Set up observability stack immediately (logging, tracing, metrics)
Proof of Work
INTERESTED IN HOW I WORK?
Let's discuss your technical challenges and how we can approach them together to build high-performing systems.