Snowball Architecture Overview and Optimization Practices

Snowball is a fintech platform with fewer than 100 employees (about half engineers) that provides news, stock quotes, and a range of financial products to over one million daily active users, handling roughly 4 billion API calls per day.

The overall architecture follows a typical mobile‑internet startup design: three client tiers (web, Android, iOS) feed into an internal data‑center where Java, Scala, Akka, Finagle, Node.js, Docker and Hadoop are used; services are exposed via an Nginx‑fronted API layer, a legacy monolith called snowball , a high‑performance quote server, an IM service built on Netty + Akka, and various business services. Infrastructure components include Redis, MySQL, MQ, ZooKeeper, HDFS and Docker containers.

During periods of market turbulence and large promotional events, Snowball faced spikes such as 30‑plus‑times normal API traffic, 5 w+ QPS on the quote server, and 5 w/s push messages from IM. To cope, the team isolated the quote server, moved data into in‑memory stores, introduced Hazelcast replication, hardened JVM parameters, and shifted heavy DB writes to asynchronous pipelines.

Key optimizations include a hybrid native‑H5 app framework for rapid releases, end‑to‑end service‑quality monitoring that attaches lightweight request metadata, redesign of the quote service to use a dedicated server with local memory, an IM architecture where each online client has a dedicated Akka actor, reduction of log overhead by bypassing Akka’s log adapter, migration from Zabbix to OpenFalcon monitoring, and a gradual move from RabbitMQ to Kafka for event handling.

The team emphasizes solving bottlenecks with minimal changes, enforcing core metrics (QPS, p99 latency, error rate), keeping the tech stack consistent and simple, preferring cache over DB and async over sync, and conducting thorough code reviews that stress scalability, fault‑tolerance, and operational ownership.

The Q&A section covers details such as IM protocol design, idempotent failure‑retry strategies, config‑center implementation, why Finagle (Thrift) was chosen over other RPC frameworks, the shift from RabbitMQ to Kafka, and deployment practices for high‑availability services.