DEV Community: Darshit Gajjar

I built DrawDesign to make system architecture easier to explain

Darshit Gajjar — Mon, 05 Oct 2026 10:56:48 +0000

A system design diagram can contain all the right boxes and still leave the reader wondering what actually happens.

Where does a request start? What does each arrow mean? Which part of the design needs a discussion?

I'm Darshit, the creator of DrawDesign, a browser-based tool for system architecture diagrams and flowcharts. In this post, I'll introduce the tool and share a small exercise you can use to make your next diagram easier to explain.

What is DrawDesign?

DrawDesign provides a canvas with shapes for the components developers often need to describe: servers, databases, load balancers, caches, message queues, API gateways, containers, and Kubernetes.

The shape library also covers networking and security, data and analytics, monitoring, and DevOps. The editor includes templates and an AI Assistant.

The use cases I want to support are straightforward:

Sketching an architecture before implementing it.
Explaining a request flow to another developer.
Practising system design discussions.
Turning a rough workflow into a diagram people can review.

But choosing a diagramming tool is only one part of the work. The more useful question is: what should the diagram communicate?

A small exercise: explain one request

Imagine you're sketching a product catalogue API. Resist the temptation to draw every service the application might eventually need. Start with one question:

How does a user request product details?

1. Draw only the participants in that path

Begin with a client, an API, and a database. Give them specific names: “Web client,” “Product API,” and “Product database” communicate more than three identical boxes labelled “service.”

Keep the scope visible in a note: “Product detail reads.” Someone looking at this diagram should not have to guess whether it also covers checkout, inventory updates, or payment processing.

2. Label the arrows

An arrow tells the reader that two components interact. Its label tells them why.

For this exercise, use labels such as:

Connection	Example label
Client to API	Request product details
API to database	Look up product by ID
API to client	Return product details or an error

You don't need to put every implementation detail on the canvas. Include the information someone needs to follow the story.

3. Add a cache as a design question

Now add a cache shape. Before drawing more arrows, write down the decisions you need to make:

What data would go into it?
How would the system handle a missing entry?
How would updated product data become visible?
What should happen if the cache is unavailable?

These questions are more valuable than adding a cache icon just because it appears in other architecture diagrams. The drawing should expose decisions that still need an answer.

4. Make uncertainty visible

Use notes to distinguish an agreed decision from an assumption. For example:

Open question: how fresh must product descriptions be?

Or:

Scope: this diagram describes reads only; inventory updates are a separate flow.

This keeps a clean-looking diagram from implying that every tradeoff has already been settled.

5. Ask another developer to narrate it

Show someone the diagram without explaining it first. Ask them where a request starts, what happens next, and which failure case deserves attention.

If their interpretation differs from yours, that is useful feedback. Rename a component, label a connection, or split an overloaded diagram into smaller views.

Where DrawDesign fits

This is the kind of exercise I'd like people to try in DrawDesign. Pick the components you need, sketch the flow, and use the result as the starting point for a discussion.

The infrastructure shapes help express the components in that story. Templates and the AI Assistant are additional starting points, but the architecture still needs your reasoning: requirements, assumptions, and tradeoffs should remain explicit.

I don't want feedback to stop at “the UI looks good.” The most useful feedback is specific:

Which component was difficult to find?
Which editing step interrupted your explanation?
What would make the diagram easier to use in a design review?
Which template would you actually reuse?

Try it with a real problem

Open DrawDesign using the link above and sketch one flow from a project you understand. Keep it small enough that another developer can follow it without a guided tour.

What is your biggest frustration with system design diagramming tools? Share a concrete example in the comments—I'd like that feedback to shape what I improve next.

EBS key important Features that every DevOps Developer Need to know

Darshit Gajjar — Sun, 23 Oct 2022 17:38:03 +0000

EBS Snapshot Archive

EBS Snapshot Archive is somthing, you have not taken data very frequently manner ex. you will taken data on monthly or yearly
it will goes on the 24 to 72 hours for restoring the Archive (Clear fancy word of Archive : Archive is something either Data/Files that you can Access them Again in the Future)
Mover a Snapshot to an "Archive tier" that is 75% cheaper
In EBS Snapshot it lower you're storage Cost as compare to EBS tier.
In EBS you have to pay money as you get the data from it

Recyle Bin for EBS Snapshot

Setup Rules to retain deleted snapshots so you can recover them after an Accidental deletion
where retention is 1 day to 1 year

Fast Snapshot Restore(FSR)

Basically this Functionality used as Diaster, lets' you have to created the snapshot AZ Region.In unfortuanitely any natural/human made diaster occur so in that situation, you will easily recover that snapshot within few minutes
when you're snapshot is so-much Big and you want to intialized fully w/o latency so this is so much helpful but you'have to spend much $$$ for that.

Thanks for Reading the Content!!

Better Utilization Of EBS Snapshot for Multiple EC2 Instances ?

Darshit Gajjar — Sun, 16 Oct 2022 18:39:30 +0000

EBS is something Like External Hard-Drive or SSD, that is used to handle External Data things.
Most Coolest Thing is we can Attach Multiple EBS to a single Instance that is seated in the same Availability Zone
But the main point is how to Architecturized the Efficient EBS so Anyone Use Very Efficiently in Various Instances without Duplication of Volume
I Attached the Efficient SC of EBS Architecture.
In Above Image First I created the 10 GB of Snapshot, then After I Architecture the Memory that will be changed and Not Changed.
In Not Changed Memory Referenced with the Memory Snap A, Then After I make Difficult Model. In that Model, I Add an Extra 2 GB of Memory.
In that Memory, I Attached two reference Snap respectively 6 GB and 4 GB, and Boom..............!
I successfully Architecturized those memories without repetition. so thing thing save customer cost.

Insight About EBS in EC2

Darshit Gajjar — Sun, 16 Oct 2022 12:01:06 +0000

As Full Stack + Devops Engineer, We Need to Handle Different Types of EC2 Instances and Instance Volumes. so in this Article I attached my Practical App Experience

When We create the NEW AWS EC2 Instance. so Default EBS is created By default. Attach SC for Ref
So As per Above EBS exist when AWS EC2 Instance Not Terminated
We can Create multiple AWS EBS and Attach with one or Multiple EC2 Instance. If that All are in same Availibility Zone
In Industry We have Various Crtical Scenario where we need EBS Volume in Different Availibility Zone. For that We need to Create EBS Snapshot for various Operation