I founded IMConnecting’s architecture as a Senior Software Engineer, and returned to scale it years later as Principal Engineer — the same product, two very different chapters.

• Chose Postgres as the system of record specifically for its ACID guarantees, given the product’s financial nature — election submissions and processing needed strict consistency that a non-relational store couldn’t offer as cleanly.
• Initially enforced that consistency with distributed XA transactions across services; later redesigned the data flow around the outbox pattern in the hot paths, preserving the same consistency guarantees while removing the distributed-transaction coordination overhead that was capping throughput.
• Built the application on the JEE spec initially, then redesigned it onto Spring Boot for wider and cheaper deployment options.
• Owned the product’s non-functional foundations across both variants (issuer and investor): support for multiple authentication schemes (RDBMS, LDAP, SSO, PKI) and API-level authorization.
• Built a capacity model from eligible-account counts and submission-concentration patterns rather than guessing at scale, and designed the retail election path to handle a peak load of ~5,200 concurrent users and ~520 API requests/second (~17 election submissions/second) — a 2× burst margin over modeled peak-hour demand.
• Cached the heaviest API’s response in Redis — its data was safely cacheable for a full day — and separately cached each user’s stock positions at beginning-of-day, removing the two most expensive lookups from the request path.
• Made election submission asynchronous: the API persisted the submission and confirmed the user immediately, with the actual election processing happening in the background — cutting API latency 90% and increasing throughput 4x across the retail path.
• Designed the opposite case — institutional investors submitting elections on behalf of up to 35k accounts in a single request — with a chunk-and-parallelize strategy: split the bulk submission into chunks, pushed them to ActiveMQ, and let parallel listeners process them, with each chunk’s status tracked in the DB and updated by its listener for aggregated progress reporting.