Simple data propagation use cases (like syncing a user preference change) take weeks of developer time to implement with Kafka, involving complex architecture decisions and custom code
A declarative data sync layer that sits on top of existing databases and message brokers, letting teams define what data changes should propagate where using configuration rather than custom code, with built-in consistency guarantees and drift detection
Subscription SaaS based on number of sync rules and throughput
The Reddit thread validates this viscerally — '3 weeks of developer time spread over months' for a simple preference sync is genuinely painful. Every microservice team hits this. The pain is recurring (each new sync use case triggers the same multi-week effort), high-frequency (companies with 10+ services face this monthly), and expensive ($15K-50K in developer time per sync implementation). However, many teams have internalized the pain as 'just how it works' — they may not be actively searching for a solution, which slightly reduces urgency.
TAM is tricky. The broader CDC/data integration market is huge ($14B+), but EventSync targets a specific wedge: teams with microservices who need cross-service data sync but find Kafka boilerplate excessive. Realistic SAM: companies with 5-50 microservices (too small for enterprise tooling, too complex for manual sync). Estimated ~50K-200K such engineering teams globally. At $500-5K/month, SAM is roughly $300M-$1B. Decent but not massive — and you're competing for budget against 'just have a developer build it' which is the real incumbent.
This is the biggest risk. The pain is real but the buyer is an engineering team, not a business unit. Engineering teams notoriously prefer to build rather than buy infrastructure tooling. The Reddit thread itself shows developers debating architectural approaches, not looking for products to buy. Competing against 'free Debezium + our own code' is hard. Willingness to pay increases at companies where developer time is explicitly valued ($200K+/dev) and engineering leadership is cost-conscious. Enterprise deals are possible but require sales motion. Developer-led adoption with freemium is more likely but slower to monetize.
This is where brutal honesty matters most. A declarative sync layer with consistency guarantees and drift detection across heterogeneous databases and message brokers is a HARD distributed systems problem. The MVP needs to: (1) capture changes from multiple DB types, (2) parse a declarative config DSL, (3) propagate changes with at-least-once delivery, (4) handle schema mapping between services, (5) detect and reconcile drift. A solo dev building this in 4-8 weeks would produce a toy that handles Postgres-to-Postgres via Kafka for one specific pattern — which is useful as a demo but far from the promise. The gap between 'working demo' and 'production-grade infrastructure tool teams trust with their data consistency' is enormous. Distributed systems bugs are notoriously hard to surface and fix.
The gap is real and clearly articulable: no existing tool combines declarative sync rules + cross-service consistency + drift detection in a developer-friendly package. Everything today is either a building block (Debezium), a pipeline tool (Airbyte/Estuary), enterprise-priced (Confluent/Striim), or a different paradigm (Materialize). The 'declarative cross-service sync' space is genuinely underserved. However, all the incumbents are 1-2 features away from closing this gap — Estuary adding drift detection, Confluent building a higher-level sync abstraction, or Debezium community creating a declarative config layer.
Extremely strong. Once a team configures sync rules for their services, those rules run continuously. Usage grows with the business — more services, more data, more sync rules. Switching costs are very high (migrating sync infrastructure is terrifying). Throughput-based pricing naturally scales with customer growth. This has all the characteristics of sticky infrastructure SaaS with strong net revenue retention. The 'land and expand' motion is natural: start with one sync use case, expand to all cross-service data propagation.
- +Validated, visceral pain that every microservice team experiences repeatedly — the Reddit thread is one of thousands of similar conversations
- +Clear competitive gap: no existing tool provides declarative sync + consistency + drift detection without massive complexity
- +Extremely strong recurring revenue characteristics: sticky infrastructure with usage-based growth and high switching costs
- +Market timing is good: microservice adoption still growing, teams increasingly exhausted by Kafka boilerplate
- +The 'build vs buy' calculation shifts as companies mature — senior eng leaders who've seen the maintenance burden are natural champions
- !Technical complexity is the #1 killer risk — building reliable distributed data sync with consistency guarantees is a multi-year, multi-engineer effort. A solo dev MVP will be fragile and limited.
- !Developer willingness to pay for infrastructure tooling is historically low — 'we'll just build it ourselves with Debezium' is the default response
- !Incumbents (Confluent, Estuary, Debezium community) could add a declarative sync layer as a feature, making EventSync a feature rather than a product
- !Trust barrier is extreme: teams won't hand their data consistency to a startup without significant proof of reliability, which takes time to establish
- !The problem may be better solved by architectural patterns (CQRS, event sourcing, saga pattern) rather than tooling — some teams will prefer education over products
Open-source CDC platform that captures database changes and streams them into Kafka. The de facto building block for event-driven data propagation, typically paired with Kafka Connect for sink connectors.
Managed Kafka platform with 200+ connectors, Schema Registry, ksqlDB and Flink for stream processing. Commercial entity behind Apache Kafka.
Real-time data pipeline platform with declarative YAML/JSON specs for defining CDC capture, transformations, and materializations in a single tool.
Enterprise real-time data integration and streaming analytics platform with SQL-like pipeline language
Streaming SQL database that maintains incrementally-updated materialized views over streaming data sources
Narrow the scope aggressively. MVP = Postgres-to-Postgres sync via existing Kafka cluster, with a YAML config file defining 'when table X changes in Service A, update table Y in Service B with this field mapping.' Support only simple field-level sync (no complex transformations). Include a basic drift detection CLI that compares source and destination counts/checksums on demand. Deploy as a Docker container that reads the YAML config and manages the sync. Skip: multi-database support, real-time drift detection, conflict resolution, schema evolution, UI. Target: replace one specific Kafka consumer/producer pair that a team built manually.
Open-source core (single sync rule, single DB type, basic drift check) → Cloud-hosted with usage-based pricing ($0.50-2/GB synced, free tier up to 1GB/month) → Team tier with multiple sync rules, alerting, and monitoring ($200-500/month) → Enterprise with SLA, audit logs, multi-region, and custom DB connectors ($2K-10K/month). Alternative path: developer tool with generous free tier, monetize via hosted management plane and enterprise support.
6-9 months to first dollar. Months 1-3: Build narrow MVP (Postgres-to-Postgres sync). Months 3-5: Alpha with 3-5 design partner teams (free, gathering feedback). Months 5-7: Harden based on production feedback, add basic monitoring. Months 7-9: Launch cloud-hosted version with usage-based pricing. First paying customers likely from design partner conversions. Reaching $10K MRR: 12-18 months. Note: this timeline assumes deep distributed systems expertise — add 3-6 months if learning CDC/streaming from scratch.
- “one of our developers has been working on implementing the solution something like 3 weeks of actual developer time, spread out over several months”
- “This is insane to me”
- “suddenly we have many sources of truth instead of one”
- “There has to be a better way”