Bird
Raised Fist0

Microservices vs Monolith - When to Split and the Hidden Costs

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway

Receives user login HTTP request

Routes request to Authentication Service

Protocol:HTTP/REST
BeforeUser submits login credentials via client
AfterAuthentication Service receives login request
Authentication Service

Checks Redis Cache for user session

Sends Redis GET to check cached session data

Protocol:Redis GET
BeforeNo cached session data for user
AfterCache miss triggers DB read
Cassandra Store

Reads user credentials data

Authentication Service queries Cassandra for user info

Protocol:CQL Query
BeforeAuthentication Service needs user data for validation
AfterUser credentials retrieved from Cassandra
Authentication Service

Validates credentials and produces event

Sends login success event to Kafka Event Bus

Protocol:Kafka Produce
BeforeUser credentials validated successfully
AfterLogin event published to Kafka
Kafka Event Bus

Delivers login event to User Service

User Service consumes login event for profile update

Protocol:Kafka Consume
BeforeLogin event available in Kafka topic
AfterUser Service receives login event
User Service

Updates Redis Cache with user session

Caches user session data for fast future access

Protocol:Redis SET
BeforeUser Service has fresh user data
AfterUser session cached in Redis
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ API Gateway   │
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────────────┐
│ Authentication Service│
└───────┬───────────────┘
        │ Redis GET (cache check)
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ Cache miss
        ▼
┌───────────────────┐
│ Cassandra Store   │
└───────┬───────────┘
        │ Data read
        ▼
┌───────────────────────┐
│ Authentication Service│
└───────┬───────────────┘
        │ Kafka Produce (event)
        ▼
┌───────────────┐
│ Kafka Event Bus│
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│ User Service  │
└───────┬───────┘
        │ Redis SET (cache update)
        ▼
┌───────────────┐
│ Redis Cache   │
└───────────────┘
Design Rationale

This architecture shows a microservices login flow where the API Gateway routes requests to the Authentication Service. The service first checks Redis cache for session data, falling back to Cassandra for durable user credentials on cache miss. After validating credentials, it publishes a login event to Kafka, decoupling authentication from user profile updates. The User Service consumes this event and updates Redis cache with session info for fast access. This design highlights microservices benefits like decoupling and scalability but also reveals hidden costs such as cache misses causing extra DB reads and event bus complexity. The vertical flow emphasizes how splitting services introduces asynchronous communication and caching layers that must be carefully managed.

Primary Focus

✓

Practice

(1/5)
1. In a MongoDB data model using the bucket pattern for time-series data, at step 3 of the write flow, the system checks if the current bucket document is full. What happens if the bucket is full at this step?
easy
A. A new bucket document is created and the write is appended there to maintain document size limits.
B. The write is rejected and the client must retry with a new bucket ID.
C. The existing bucket document is updated by splitting it into two smaller documents automatically.
D. The write is appended to the existing bucket document regardless of size, risking document growth beyond limits.

Solution

  1. Step 1: Understand bucket pattern write flow

    Writes append to a bucket document until size or time limits are reached.

  2. Step 2: Behavior when bucket is full

    System creates a new bucket document to avoid exceeding MongoDB's 16MB document size limit.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    New bucket created to respect document size limits [check]
Hint: Full bucket triggers new document creation to avoid size limit [check]
Common Mistakes:
2. For a system requiring per-user rate limits with minimal latency, which architecture is better and why?
medium
A. Service-layer counters with no database persistence for simplicity
B. Centralized database counters updated synchronously on every request for accuracy
C. Client-side counters with server verification on every request for trustworthiness
D. Distributed in-memory counters at the API Gateway with periodic async database sync for scalability

Solution

  1. Step 1: Compare latency and scalability

    Synchronous DB updates cause high latency and DB bottlenecks; client-side counters are untrustworthy; service-layer without persistence risks data loss.

  2. Step 2: Evaluate distributed in-memory counters

    API Gateway counters provide low latency and scalability; async DB sync ensures eventual consistency and durability.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Distributed in-memory counters balance latency and scalability [check]
Hint: Async DB sync + in-memory counters = low latency + scalability [check]
Common Mistakes:
3. At 10x scale, which component of a distributed Count-Min Sketch system is most likely to fail first and why?
hard
A. The network bandwidth saturates due to large sketch state synchronization
B. The sketch arrays in memory overflow due to fixed size limits
C. The hash functions become slower, increasing latency linearly
D. The centralized coordinator bottlenecks due to serializing all update requests

Solution

  1. Step 1: Identify bottleneck in distributed updates

    Centralized coordinator serializes updates to maintain consistency, limiting throughput.

  2. Step 2: Analyze other components

    Network bandwidth and hash function speed scale better; sketch arrays have fixed size but don't overflow.

  3. Step 3: Understand scale impact

    At 10x scale, coordinator becomes overwhelmed, causing update latency and failures.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Central coordinator serialization bottlenecks updates at scale [check]
Hint: Central coordinator serializes updates, bottlenecking at scale [check]
Common Mistakes:
4. At 10x scale, which component in the real-time analytics pipeline is most likely to fail first and why?
hard
A. Kafka brokers, due to partition leader overload and disk I/O bottlenecks
B. Dashboard frontend, as WebSocket connections exceed browser limits
C. Flink cluster, because stateful operators require large memory and checkpointing slows down
D. OLAP store, because complex ad-hoc queries overwhelm its indexing and caching layers

Solution

  1. Step 1: Analyze Kafka broker bottlenecks at scale

    Kafka brokers face partition leader overload and disk I/O saturation as event volume grows 10x.

  2. Step 2: Compare other components

    Flink scales with more nodes; OLAP stores can shard; dashboards scale horizontally; Kafka's broker disk and network limits are hardest to scale first.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka broker disk I/O saturates first at 10x event volume [check]
Hint: Kafka broker disk I/O saturates before others scale [check]
Common Mistakes:
5. At 10x scale, which component in the Google Search architecture is most likely to become the first bottleneck, and why?
hard
A. The distributed file system storing raw crawled pages, because storage bandwidth saturates before compute
B. The crawler's URL Frontier, because it must maintain global URL ordering and politeness state, which is hard to shard
C. The query serving layer, because caching effectiveness drops and latency-sensitive lookups increase exponentially
D. The PageRank computation cluster, because the graph size grows superlinearly, increasing memory and CPU demands drastically

Solution

  1. Step 1: Analyze scaling challenges per component

    The PageRank cluster faces superlinear growth in graph edges, causing memory and CPU bottlenecks.

  2. Step 2: Compare other components

    URL Frontier can shard with heuristics; query serving scales with caching; storage bandwidth scales better than PageRank compute.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    PageRank graph growth causes first bottleneck at 10x scale [check]
Hint: PageRank graph grows superlinearly -> first bottleneck [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard