← Remitly Interview Insights

Remitly·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
Jun 2026

Summary

System design round at Remitly for a software engineer role. The whole thing was basically one big URL shortener question but they expected you to go several layers deep across a lot of dimensions, not just sketch a box diagram and call it done.

Questions Asked (1)

Q1

Design a production-ready URL shortening service, covering the public API, database schema, ID generation with collision avoidance, caching strategy, partitioning and replication, rate limiting, analytics, TTL cleanup, high availability, and trade-offs under different traffic patterns.

System DesignTechnical Trade-offsData Modeling
Author's notes

This question sounds scoped but it really isn't.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., read/write ratio, QPS, latency, retention) to frame trade-offs. Then walk through the design in layers: API, data model, ID generation, caching, partitioning, rate limiting, analytics, TTL cleanup, and HA. Finally, discuss trade-offs under different traffic patterns and how you'd evolve the system.

Pro tip: Anchor your design around the read-heavy nature (100:1 read/write) and use a base62-encoded distributed ID generator like Snowflake to avoid collisions without coordination. Mention that analytics should be decoupled via async logging to avoid impacting latency.

1. Clarify Requirements and Scale

Ask about expected QPS, read/write ratio, latency SLA, retention period, and custom alias needs. Estimate storage and bandwidth to inform design choices.

2. Design API and Data Model

Define REST endpoints (POST /shorten, GET /{code}, GET /analytics/{code}) and a schema with short_code as primary key, original_url, created_at, expires_at, and user_id. Consider a separate analytics table or store.

3. ID Generation and Collision Avoidance

Use a distributed ID generator (e.g., Snowflake) to produce unique 64-bit IDs, then base62-encode to short codes. Alternatively, use a key generation service with pre-allocated ranges to avoid collisions.

4. Caching, Partitioning, and Replication

Cache hot URLs in Redis with LRU eviction and TTL. Partition data by short_code hash for even distribution. Use replication for read scalability and failover.

5. Rate Limiting, Analytics, TTL Cleanup, and HA

Implement rate limiting per user/IP using token bucket. Log analytics asynchronously to Kafka. Use a background job to delete expired URLs. Ensure HA via multi-AZ deployment and health checks.

Key Points to Mention

  • Base62 encoding of distributed IDs (e.g., Snowflake) for collision-free short codes
  • Read-through cache with Redis and TTL to handle read-heavy traffic
  • Database partitioning (sharding) by short_code and replication for scalability and availability
  • Rate limiting using token bucket or sliding window to prevent abuse
  • Asynchronous analytics logging to avoid impacting request latency
  • TTL cleanup via background jobs and trade-offs between consistency and availability (CAP theorem)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.