System Design Interview Questions for Java Backend Developers (With Real Answers)

⏱️ 9 min read | 📚 Updated July 2026

Picture this: you’ve sailed through the coding round — reversed a linked list, nailed the sliding window problem — and then the interviewer leans back and says, “Now, design a URL shortener like bit.ly.” The room goes quiet. This is where good Java developers freeze, not because they lack knowledge, but because nobody told them what “design” actually means in an interview context.

System design rounds are now standard at EPAM, product startups, and increasingly at TCS and Infosys for senior roles (SSE and above). Even Wipro’s digital tracks test this for L2+ hires. This article walks you through what interviewers actually evaluate, the four most commonly asked design problems for Java backend roles, the mistakes that kill otherwise strong candidates, and a concrete prep plan you can start today.

By the end, you’ll know how to structure your answer, what to draw on that whiteboard, and the exact follow-up questions to expect for each problem.

Table of Contents

• What Interviewers Are Actually Testing
• How System Design Rounds Work at Different Companies
• The Four Core Design Problems You Must Know
• Common Mistakes and How to Fix Them
• A Realistic 4-Week Prep Plan
• Frequently Asked Questions

What Interviewers Are Actually Testing

System design isn’t a quiz. There’s no single correct answer. The interviewer is watching how you think — do you clarify requirements before drawing boxes? Do you know why you’d pick Redis over Memcached for a specific use case? Can you estimate load without a calculator?

Three things matter most:

• Requirement gathering: Always ask — reads vs. writes ratio, expected QPS, consistency requirements, SLA. This shows production awareness.
• Trade-off articulation: “I’m choosing eventual consistency here because writes are infrequent and read latency matters more.” That sentence alone separates senior from junior thinking.
• Java-specific depth: For backend roles, they’ll expect you to go one layer deeper — “I’d use a Spring Boot service with a connection pool of 50 via HikariCP” rather than just “a backend server.”

Pro Tip: Spend the first 3-5 minutes asking clarifying questions before you touch the whiteboard. Interviewers at EPAM and startups specifically note when a candidate jumps straight to drawing — it signals poor real-world engineering habits.

How System Design Rounds Work at Different Companies

Company	Round Format	Typical Duration	What They Emphasize
TCS / Infosys	High-level design, mostly verbal	30–45 min	Basic architecture, DB choice, scalability concepts
Wipro Digital	Whiteboard + follow-up coding	45–60 min	Microservices patterns, REST API design
EPAM	Deep dive, often multi-part	60–90 min	Bottlenecks, failure scenarios, CAP theorem application
Startups	Conversational, iterative	45–60 min	Cost awareness, build vs. buy, speed of delivery

The Four Core Design Problems You Must Know

1. Design a URL Shortener

This is the classic starter. The interviewer wants to see if you understand hashing, redirection, and scale. Start with estimates: if you handle 100 million URLs with ~500 bytes each, that’s ~50 GB of storage — totally manageable on a single PostgreSQL instance with read replicas.

The core challenge is generating a unique 6–8 character short code. Many candidates immediately say “use UUID” — that’s the wrong answer. A UUID is 36 characters. Instead, use Base62 encoding on an auto-incremented ID.

// Base62 encoding for short URL generation
public class Base62Encoder {
    private static final String CHARS =
        "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

    public static String encode(long id) {
        StringBuilder sb = new StringBuilder();
        while (id > 0) {
            sb.append(CHARS.charAt((int)(id % 62)));
            id /= 62;
        }
        return sb.reverse().toString(); // e.g., id=1000 → "qi"
    }
}

This gives you 62^6 ≈ 56 billion unique codes from a 6-char string. The follow-up they’ll ask: “What if two users shorten the same URL?” You store the original URL as a key and return the existing short code — a simple lookup in Redis before hitting the database.

For redirection, use HTTP 301 (permanent, cached by browser) vs HTTP 302 (temporary, always hits your server). If you need analytics per click, use 302. Knowing this distinction immediately impresses interviewers.

2. Design a Rate Limiter

Rate limiters appear constantly for API gateway and fintech roles. The first question to ask: per user, per IP, or per API key? The algorithm matters — and you should know at least two.

The Token Bucket algorithm is the industry default (used by AWS API Gateway). Tokens refill at a fixed rate; each request consumes one. The Fixed Window Counter is simpler but has a boundary bug — a user can fire 2x the limit in a short window spanning two periods.

// Token Bucket using Redis (pseudo-implementation)
// Key: "rate_limit:{userId}", Value: remaining tokens
public boolean isAllowed(String userId, Jedis jedis) {
    String key = "rate_limit:" + userId;
    long tokens = jedis.incr(key); // atomic increment
    if (tokens == 1) {
        jedis.expire(key, 60); // 60-second window
    }
    return tokens <= 100; // allow 100 requests/min
}

Real follow-up: "How do you handle distributed rate limiting across 10 microservice instances?" The answer is a shared Redis cluster — each instance checks and decrements from the same key atomically using INCR and EXPIRE. Lua scripting in Redis makes this fully atomic. This is exactly the kind of Java-meets-infrastructure depth that EPAM interviewers love.

3. Design a Notification System

Push notifications, emails, SMS — this problem tests your event-driven architecture knowledge. The naive answer is synchronous: user triggers action → your service calls the email API. That fails at scale. One slow SMTP call blocks your thread pool.

The correct architecture: your Java service publishes an event to a message queue (Kafka or RabbitMQ). Separate consumer services — EmailConsumer, SMSConsumer, PushConsumer — each pick up events and call their respective third-party APIs independently.

// Publishing a notification event to Kafka
@Service
public class NotificationPublisher {
    @Autowired
    private KafkaTemplate kafkaTemplate;

    public void send(String userId, String type, String message) {
        NotificationEvent event = new NotificationEvent(userId, type, message);
        kafkaTemplate.send("notifications", userId, event);
        // Partitioning by userId ensures ordering per user
    }
}

Key design decisions to mention: idempotency (what if Kafka delivers the message twice — you check a notificationId in a deduplication table), retry with exponential backoff for failed deliveries, and a dead-letter queue for permanently failed messages. Mentioning these without being prompted signals real production experience.

4. Design a Caching Layer

Caching questions are sneaky — they seem simple until the interviewer asks about cache invalidation. Start by identifying what to cache: expensive DB queries, session data, computed aggregates. Don't cache everything.

Know these three patterns cold:

• Cache-aside (lazy loading): App checks cache first; on miss, loads from DB and populates cache. Most common. Risk: cache stampede on cold start.
• Write-through: Every write goes to cache and DB simultaneously. Consistent, but higher write latency.
• Write-behind (write-back): Write to cache first, async flush to DB. Fast writes, but risk of data loss on cache failure.

In Java with Spring Boot, you'd use @Cacheable with a Redis backend via Spring Cache abstraction. The follow-up question is always: "How do you handle cache invalidation?" The honest answer: it's hard. Use TTL as your safety net, and explicit eviction on writes with @CacheEvict. Mention that distributed caches introduce network latency, so for sub-millisecond requirements, consider an in-process cache like Caffeine as an L1 cache in front of Redis.

For deeper coverage of Java memory management that underlies caching decisions, check our guide on advanced Java concepts.

Common Mistakes and How to Fix Them

The single most common mistake I see: jumping to microservices immediately. A candidate asked to design a notification system will say "I'll have 12 microservices" before establishing even basic requirements. Start monolithic, then identify boundaries to split. Interviewers at startups especially penalize premature complexity.

Second mistake: ignoring failure modes. Every component you draw should have a "what if this dies?" answer. If your Redis cache goes down, can your app still function? Yes — it falls back to the database (slower, but alive). Resilience4j in Spring Boot gives you circuit breakers with a few annotations for exactly this scenario.

Third mistake: vague database answers. "I'll use a database" is not an answer. Know when to choose PostgreSQL (relational, ACID, complex queries) vs. Cassandra (high write throughput, wide-column, eventual consistency) vs. MongoDB (flexible schema, document data). For a URL shortener, PostgreSQL. For a notification audit log with billions of rows, Cassandra.

Pro Tip: Always mention observability — logs, metrics, and traces. Saying "I'd add Micrometer metrics exposed to Prometheus with Grafana dashboards" takes 10 seconds and immediately marks you as someone who's run things in production, not just built them.

You can brush up on thread-safety and concurrency fundamentals — often probed as follow-ups in system design — in our Java basics deep-dive.

A Realistic 4-Week Prep Plan

Don't try to learn everything. Here's what actually works for Java backend candidates preparing in 4 weeks:

• Week 1: Master the vocabulary — CAP theorem, consistency models, SQL vs NoSQL tradeoffs. Read the Oracle Java documentation for core concurrency APIs you'll reference in design discussions.
• Week 2: Design URL shortener and rate limiter from scratch. Time yourself — 45 minutes per problem. Write down your design, then poke holes in it.
• Week 3: Design notification system and caching layer. Focus on failure scenarios specifically — what breaks and why.
• Week 4: Mock interviews. Find a peer, use LeetCode's system design discussion board for real interview experiences, and practice explaining trade-offs out loud — articulation is half the score.

If you want structured problem sets to reinforce Java fundamentals alongside system design, our premium interview preparation track covers both in a structured progression.

Frequently Asked Questions

Do TCS and Infosys really ask system design questions?

For fresher and junior roles, rarely. But for SSE, Technical Lead, and digital transformation tracks (3+ years experience), yes — expect at least a high-level design discussion. It's often verbal rather than whiteboard, but the concepts are the same.

Should I use microservices in every system design answer?

No — and doing so is a red flag. Start with a simple, modular monolith, then explain at what scale or team size you'd introduce service boundaries. Interviewers want to see you understand the cost of distributed systems, not just the buzzword.

How detailed should my database schema be in a system design round?

Enough to show you've thought about it — key tables, primary/foreign keys, and any indexes you'd add. For a URL shortener, that means a `urls` table with `id`, `short_code`, `original_url`, `user_id`, `created_at`, and an index on `short_code`. You don't need to write full DDL unless asked.

What's the difference between horizontal and vertical scaling, and when does it come up?

Vertical scaling means upgrading your server (more RAM, better CPU) — quick but has a ceiling. Horizontal scaling means adding more servers behind a load balancer — theoretically unlimited but adds complexity (shared state, session management). This comes up whenever you discuss handling increased traffic in any design problem.

How do I handle the "estimate the scale" part when I have no idea?

Use round numbers and think aloud. "Twitter has ~300 million users; if 1% are active daily and each sends 2 tweets, that's 6 million writes/day, or ~70 writes/second." The interviewer cares about your reasoning process, not precision. Practice back-of-the-envelope math daily for a week and it becomes instinctive.

Is knowing Spring Boot enough, or do I need to know Kafka, Redis, etc.?

Spring Boot is your foundation, but system design requires knowing the ecosystem around it. You don't need to be a Kafka administrator, but you should know what it does (durable, ordered message streaming), when to use it vs RabbitMQ (Kafka for high-throughput event streaming; RabbitMQ for task queues), and how a Spring Boot service would produce/consume messages using spring-kafka.