•
2 min read
Platform Architecture & Multi-Tenancy

As the platform’s engineering lead, I made the core architectural bets this platform runs on: how services are bounded, how tenants are isolated, and how state changes propagate.

  • Chose a modular monolith over a microservices fleet: one deployable unit (~170K LOC across 16+ modules) with service boundaries enforced in code, not convention — cross-service reads only through dedicated API modules, cross-service writes only through Kafka events, no service reaching into another’s database. That trade bought the operational simplicity of a single build/deploy/transaction boundary at our team’s current scale, while keeping the boundaries real enough to carve out standalone services later if scale ever demands it.
  • Built an event-driven core on Kafka with well-defined domain events (proto definitions, the outbox pattern, end-to-end event validation) in place of point-to-point service calls.
  • Made that same event stream double as the platform’s analytics feed: a Kafka schema registry feeds an ELT pipeline straight into Databricks, so the data/reporting layer runs on events already produced for the application rather than a separate CDC pipeline bolted on afterward.
  • Designed the platform for multi-tenancy from the core up, with OpenFGA-based fine-grained authorization so tenant-, role- and resource-level access checks live in one dedicated layer instead of being re-implemented per service.
  • Exposed one gRPC API surface for every client — native gRPC for mobile, gRPC-Web for the browser — so web and mobile share a single backend contract instead of maintaining REST and gRPC in parallel.
  • Built the platform to 12-factor principles: configuration and secrets injected via environment (centralized through a secrets manager) rather than baked into code or images, stateless horizontally-scalable services, and logs treated as event streams.