workOwonworkOwonA New Way to Connect
HomeFeedJobsCommunitiesEventsFeaturesAbout workOwon
HomeFeedJobsCommunitiesEventsFeaturesAbout workOwon
HomeCommunitiesSystem Design Deep Dives

High level:

RM

Rohan Malhotra

Staff Engineer @ Orbitly | Distributed systems, Go, Postgres | Writing about architecture tradeoffs

30 Sept 2026· System Design Deep Dives

High level: 1. Picked tenant_id as the shard key (every query already had it) 2. Built a routing layer in the app: tenant → shard lookup cached in memory 3. Logical replication to copy each tenant group to its new shard 4. Dual-read verification for a week (compare results, alert on mismatch) 5. Cut over tenant groups in batches during low traffic, with a 1-click rollback Total: 4 months, 2 engineers. The dual-read week found 3 bugs that would've been incidents.
8 reactions3 comments

Comments

  • AS

    Aarav Sharma30 Sept 2026

    The dual-read verification step is underrated. Did you do it at the query level or the API level?

  • RM

    Rohan Malhotra30 Sept 2026

    @Aarav API level for the critical read paths. Query level was too noisy with timestamps.

  • DJ

    Dhruv Joshi30 Sept 2026

    This is gold. Most system design content stops at 'just shard by user ID'.

Join the conversation

Join workOwon to react, comment and follow people and communities you care about.

Log inJoin now

Popular communities

See all