Engineering Decisions

OZON needed a high-concurrency search microservice for 200M warehouse items. Java/Spring was the team default.

Go's goroutine model handles 10K concurrent connections with ~50MB RAM vs. Java's thread-per-request model needing ~2GB. Single binary deployment eliminates JVM overhead. The team already knew Go.

Fewer libraries than Java ecosystem. String manipulation is more verbose. No generics at the time (pre-Go 1.18).

PostgreSQL FTS was hitting 8-10s at 200M documents. A search engine was clearly needed.

ES supports custom analyzers for Russian transliteration (a hard requirement). Fuzzy matching and phonetic analysis work out of the box. Horizontal sharding is transparent. Team had prior experience.

Operational complexity vs. Postgres (separate cluster, JVM memory). Eventual consistency between Postgres (source of truth) and ES (search replica). Complex upgrade path.

ES index needs to stay current with the product catalog. Options: poll DB, use CDC, or event stream.

Catalog service already published events to Kafka. Consuming them is simpler than setting up Debezium CDC. Kafka's consumer group semantics allow replay on failure. Sub-2s lag is acceptable.

Depends on catalog service publishing correct events (coupling). Requires handling out-of-order events. CDC would be more robust for high-volume bulk updates.

Parking cameras need to push occupancy events to the backend. Cameras are on a campus LAN.

Cameras are resource-constrained (embedded C, limited RAM). MQTT is designed for IoT — small payload overhead, persistent connections, QoS levels for at-least-once delivery. Single broker handles hundreds of cameras.

Adds MQTT broker as infrastructure dependency. Topic schema needs discipline or becomes chaotic. Harder to debug than REST.