BobaBoba

I optimized for speed of delivery. Each engineer was strongest in a different language, so I built Boba as services and let everyone ship in the language they're fastest in, then put Go and Rust where performance decides outcomes: the real-time feed, the Solana sender and the order engine.

Every service owns one job, and a bad deploy in one never stops people trading. The cost is operations and consistency across 25 services. The next two decisions are how I paid it.

With 25 services and no dedicated DevOps engineer, every hour on IAM roles, load balancers and deploy pipelines was an hour not spent on Boba. I put the platform on Railway instead.

Every service deploys straight from the monorepo into separate dev, staging and production environments, and every pull request gets its own environment in CI. Deployments went from a headache to something anyone on the team can test against in minutes.

AWS offers more control and gets cheaper at scale, and I traded that away on purpose: at our size, speed mattered more. It's also what makes microservices workable for a team of four, because the 25th service is as easy to deploy as the first.

Twenty-five services in four languages only work if the hard parts are solved once. Adding an EVM chain used to mean editing about 60 places across five languages, and a missed one never failed a build. Now it's one entry in chains.json, a generator run, and every service picks it up.

The same rule runs through the database, Redis, swap parsing and observability: solved once in the monorepo, used by every service. Adding a chain or upgrading a dependency is config, not a chore.