ScaleDojo

ScaleDojo is where developers go when they realize coding tutorials are not enough.

Most write code. Few design systems. Come be one of the few :

[ScaleDojo @team_scaledojo]

Your architecture has 15 components.

The system works.

Your interviewer asks:
“Which ONE would you remove?”

What do you choose and why?

#SystemDesign #SystemArchitecture #EngineeringTradeoffs

[ScaleDojo @team_scaledojo]

@SanhitaDawn Agreed. Independent subscriptions allow channel-specific scaling and failure isolation without requiring one worker pool to handle every provider.

[ScaleDojo @team_scaledojo]

You're banned from using Kafka.

Design a notification system for:

10M notifications/day

Email + SMS + Push

Retries required

What replaces it?
#SystemDesign #NotificationSystem #DistributedSystems

[ScaleDojo @team_scaledojo]

@Khushbootfh Good choice. How would you prevent a poison message from retrying indefinitely and blocking other notifications?

[ScaleDojo @team_scaledojo]

We’d use a stable idempotency key per notification and channel, backed by a unique DB constraint to prevent duplicate processing. Retries reuse the same key, and provider-side idempotency helps cover failures after a successful send but before acknowledgment. For providers without it, we’d reconcile delivery status before retrying.

[ScaleDojo @team_scaledojo]

Find the hidden SPOF:

API × 10

Redis × 3

DB × 2

Everything is replicated.

What could STILL take the whole system down?

#SystemDesign #HighAvailability #FaultTolerance

[ScaleDojo @team_scaledojo]

Find the hidden SPOF:

API × 10

Redis × 3

DB × 2

Everything is replicated.

What could STILL take the whole system down?

#SystemDesign #HighAvailability #FaultTolerance

[ScaleDojo @team_scaledojo]

PostgreSQL: 180 GB · 12K QPS · 42% CPU · 180ms P99

Someone says: “Let's shard it.”

Would you?

Why?

#PostgreSQL #SystemDesign #DatabaseScaling

[ScaleDojo @team_scaledojo]

@SanhitaDawn Exactly. Queue depth is the symptom; the gap between arrival and completion rates tells us why it's growing.

[ScaleDojo @team_scaledojo]

Queue depth keeps increasing.

Workers are at 100% CPU.

What do you check BEFORE adding more workers?

#SystemDesign #DistributedSystems #PerformanceEngineering

[ScaleDojo @team_scaledojo]

@RiteshGupt_09 Good catch. Retries can create a feedback loop where failed jobs consume the capacity needed to recover.

[ScaleDojo @team_scaledojo]

@simanta_sarma_ That's the diagnostic sequence I'd follow too: measure throughput, execution time, retries and queue age before choosing a fix.

[ScaleDojo @team_scaledojo]

A worker charges a customer...

Then crashes before acknowledging the message.

The message is delivered again.

How do you prevent a double charge?

#SystemDesign #DistributedSystems #Idempotency

[ScaleDojo @team_scaledojo]

Ready to level up your engineering skills? 🥋

Celebrate Navratri with 50% OFF on ScaleDojo! 🎉

Use code NAVRATRI50 at checkout.

Offer ends October 20. Don't miss out!

#Navratri #SystemDesign #GenAI #ScaleDojo

[ScaleDojo @team_scaledojo]

@MansiCodez try -> build -> scale

[ScaleDojo @team_scaledojo]

@thisdudelikesAI big drop

[ScaleDojo @team_scaledojo]

@KirkDBorne try -> build -> scale

[ScaleDojo @team_scaledojo]

@RiteshGupt_09 Good distinction. Detecting concurrent writes and deciding how to resolve them are two separate problems.

[ScaleDojo @team_scaledojo]

Two regions accept writes.

The network splits for 60 seconds.

Both accept conflicting updates.

When the partition heals, who wins?

#SystemDesign #DistributedSystems #CAPTheorem

[ScaleDojo @team_scaledojo]

@kanishk_jainn Right. Idempotency prevents duplicate processing of the same operation; it doesn't decide which of two distinct conflicting updates should win.

[ScaleDojo @team_scaledojo]

@simanta_sarma_ Agreed. The conflict policy should be designed around the business invariant before choosing a resolution mechanism.