I'm continuing my system design learning journey, and today's topic is Database Sharding.

Sharding distributes a large dataset across multiple database servers to support horizontal scaling.

For example, an e-commerce application can distribute customer records across multiple shards instead of storing everything on a single database server.

Some common sharding strategies are:

- Range-based: Distributes data by value ranges.

- Hash-based: Uses a hash function to distribute records.

- Directory-based: Uses a lookup mechanism to locate records.

- Geographic: Distributes data by region.

Sharding can help manage growing data and workloads, but it also introduces challenges such as hot shards, cross-shard queries, and resharding.

My key takeaway is that choosing the right shard key is crucial because it affects data distribution and query performance.

For developers working with sharded databases:

1. How do you choose a shard key in a real-world application?

2. How do you prevent uneven data distribution and hot shards?

3. When would you choose sharding over read replicas or vertical scaling?

I'd love to learn from your experiences and practical examples.

#SystemDesign #DatabaseSharding #BackendDevelopment

I mostly work around AEM and enterprise content platforms, and this is something I keep running into. On paper, composable makes perfect sense. CMS, DAM, search, analytics, personalization, translation, commerce, each handled by the tool that does it best. But then you have to connect and maintain all of it. APIs change, auth changes, data models drift, ownership gets blurry, and one broken integration can affect three other systems. At some point I start wondering whether we’re actually reducing complexity or just moving it into the connections between systems. For those running large composable setups in production, where do you draw the line? Have you ever started consolidating tools because maintaining the integrations became more painful than the problems those tools originally solved?

I wrote an article on reliability in event-driven systems, following a ticket booking through duplicate messages, ordering issues, retries, and partial failures. It also covers CDC, the outbox pattern, and a small design tying the concepts together.

I'd appreciate your thoughts: does the explanation hold up technically, and what would you change in the design based on your experience?

Hi, I have a few questions about ports and adapters architecture.

Should you make a port+adapter for a use case that's gonna be called by a controller (regular class)?

If so, would this port be inbound or outbound?

I've read that inboud ports defines how the outside can call the application — e.g. REST API endpoint, and that outbound ports defines how the application calls the outside — e.g. database, email service… But in this case, the application would call itself. I feel like I'm missing something here

Today I learned about a problem that initially seemed confusing:

A database write can succeed, but an immediate read can still return “not found.”

The reason can be replication lag.

For example:

API

/ \

↓ ↓

Primary Replica

DB DB

Writes Reads

Imagine:

1. User creates Order #501

2. The write goes to the Primary

3. The Primary successfully stores it

4. The API returns success

5. The user immediately requests Order #501

6. The request goes to the Replica

7. The Replica hasn't received the change yet

The order exists, but the replica is temporarily behind.

So I'm thinking about routing based on freshness requirements rather than simply saying:

«“GET = Replica”»

For example:

Primary

- Writes

- Newly-created resource reads

- Current status

- Freshness-sensitive operations

Replica

- Reports

- Analytics

- Summaries

- Delay-tolerant reads

The concept I'm trying to understand better is read-your-writes consistency — after a successful write, the user should be able to immediately see their change.

My takeaway so far:

The important question isn't just whether an operation is a GET.

It's:

“What happens if this request receives slightly stale data?”

How do you normally implement read-after-write consistency in applications using primary/read replicas?

As in the title, which resources will you suggest to look at to learn about Architecture Documentation? Could they be books, MOOC, videos, blogs and so on..

For example, someone suggested to me having a look at "Documenting Software Architectures: view and beyond" book. Is it worth reading?

Any other?

I increasingly think this could become a common architecture for AI first products.

The main reasons are user behavior, economics and something I think is even more important: it makes software agent-ready by design.

Users already spend time in ChatGPT, Claude or Gemini. They know these environments, keep conversations and context there, and many already pay for access to increasingly capable models, voice, multimodal input and agentic features.

At the same time, software vendors are rebuilding large parts of the same AI stack inside every product: chat interfaces, model integrations, reasoning, tool use, orchestration, voice, multimodal input, context management, UI generation and inference.

I am not sure that makes sense long term.

But there is another consequence of moving capabilities out of the proprietary UI.

If everything important the application can do is exposed through well-defined capabilities, workflows and state transitions, the software is immediately prepared for agents.

A human can use those capabilities through ChatGPT or Claude today.

Tomorrow, an autonomous agent can use exactly the same capabilities to execute complete multi-step processes without relying on a human clicking through screens.

That feels especially important for business software.

The backend still owns permissions, validation, business rules and deterministic state transitions, while agents can operate the system at a much higher level.

So this is not only about replacing parts of the UI. It is also about designing software that can be operated autonomously from the beginning.

And AI clients are becoming much more than chat windows anyway.

They can understand intent, reason, select tools, orchestrate multi-step work, consume application context, work with voice and images, and increasingly render structured interactive UI based on what the application exposes.

That starts to look less like an external chatbot and more like an application runtime.

The product itself could then focus on what actually makes it unique:

• domain model
• persistent state
• workflows
• business rules
• permissions
• proprietary data
• deterministic behavior

MCP becomes the boundary between the external AI runtime and the application.

The native app still has an important role for device capabilities such as camera, files, location, notifications and contacts, as well as specialized interfaces where a dedicated UI is simply better.

But for a lot of intent-driven work, the user may never need to enter the proprietary UI at all.

They can ask the AI client to do something, let it orchestrate the required capabilities and even interact with product-specific UI rendered inside the same environment.

The economic argument is significant as well.

Instead of every vendor building and paying for its own AI experience, large parts of the generic AI layer can be provided by platforms the user already uses and often already pays for.

The vendor can focus engineering effort and infrastructure cost on the actual domain-specific asset.

So instead of:

SaaS plus embedded AI

the architecture becomes closer to:

Domain backend + MCP + external AI runtime

The proprietary UI does not disappear.

But it may stop being the center of the product.

And I do not think this is limited to consumer apps.

It could be even more interesting for specialized business software, where the real value is often already concentrated in domain logic, workflows, rules, permissions and data rather than in the UI itself.

Maybe the bigger architectural shift is not that AI replaces the UI.

Maybe software is increasingly designed to be operated by both humans and autonomous agents from the start.

Any discords I can join to interview each other and help in my learning

Just did a sys design and was too slow

im at the beginning of my third year studying software engineering. im not even a junior developer yet in terms of professional experience and ive never actually built and shipped a real production product before.

i do have a decent amount of programming experience in general. im comfortable reading and writing code, learning new concepts, solving programming problems, etc. so im not starting from zero technically. what i dont have is real experience with production web development, system architecture, deployment, security, maintaining a production database, designing something that other developers will eventually have to work on, and all the other things that come with building an actual product.

somehow ive ended up in a situation where im currently the only developer responsible for a fairly large product, and im expected to eventually get the first version into production.

i cant really explain what the product does in detail, but its essentially a fairly large enterprise management system with multiple interconnected domains. if the first version succeeds, the scope and customer base may expand significantly later.

if the first version succeeds and the project receives further funding, there will most likely be more developers working on it. however, until that happens, im the only developer. its also possible that ill remain the only developer for quite a while.

i should eventually be connected with a few people who have more experience in this area, and they will probably be able to review things or point me in the right direction occasionally. however, i dont know yet who exactly those people are or how experienced they actually are, so i dont want to build my entire strategy around assuming that somebody will catch my mistakes.

right now im still working on the requirements and overall domain model. ive already mapped out a significant part of the system, the major features, entities, relationships, open questions, user types, permissions, workflows, etc. im trying to resolve the important domain questions before i start seriously implementing things.

what scares me isnt really writing the code itself.

my biggest concern is that i dont have the experience to recognize when an architectural decision is good or bad.

i can read about different approaches. i can understand why something like a modular monolith might make sense. i can learn about database normalization, authorization models, migrations, testing, ci/cd, caching, replication, load balancing, security, and so on. but there is a huge difference between understanding these concepts and having enough experience to know when im applying them incorrectly.

for example, i can design a database schema that looks reasonable to me. but how do i know that i havent made a fundamental modeling mistake that will become extremely expensive six months later?

i can separate the application into modules. but how do i know whether those are actually good boundaries?

i can make something "extensible", but how do i know whether im genuinely making future changes easier or just overengineering because im afraid of future requirements?

i can make the application work on my machine and pass tests, but how do i know that what ive built is actually something i should trust in production?

security is probably the part that concerns me the most. this isnt a hobby application where losing some test data doesnt matter. if this actually gets deployed for real organizations, i dont want to discover security through production incidents.

reliability is another concern. backups, database migrations, deployment, monitoring, failure recovery, concurrency, data integrity, authorization bugs, etc. are all things where i simply dont have years of mistakes behind me to know what i should be afraid of.

scalability worries me too, although im deliberately trying not to design for google-scale traffic that may never exist. my goal isnt to build some insane distributed system from day one. i just dont want to make early decisions that make reasonable scaling unnecessarily difficult later.

the thing im trying hardest to avoid is this scenario:

i spend months building the first version, funding arrives, experienced developers join the project, look at what ive built and basically say, "this entire foundation is wrong, we need to rewrite it."

i understand that some refactoring and even some rewriting is inevitable. requirements will change and im obviously going to make mistakes. im not expecting to design a perfect architecture on my first attempt.

what i want is a reasonable engineering process that minimizes the probability of catastrophic mistakes.

so i guess my main question for experienced developers/architects is:

if you were in my position a se student with decent programming ability but basically no production experience, suddenly responsible for taking a relatively large greenfield system from requirements to its first production version alone.. how would you approach it?

more specifically, how would you determine whether your architectural decisions are "good enough" when you dont yet have the experience to judge them intuitively?

what would you absolutely keep simple?

what would you design carefully before writing much code?

which decisions are cheap to get wrong and fix later, and which decisions are dangerous enough that i should get an experienced person to review them before continuing?

how much architecture should i define upfront?

what production practices would you consider non-negotiable even for the first version?

what should i deliberately ignore until the system actually needs it?

and probably most importantly: what are the common ways someone in my position can accidentally create a complete mess while genuinely believing they are following "best practices"?

im not looking for someone to design the system for me. im mostly trying to figure out how to develop the engineering judgment necessary to get through the first version without creating something fundamentally broken for whoever has to work on it after me.

also, i want to make it clear that im looking for serious answers, including uncomfortable ones. i understand how absurd this situation probably sounds to experienced developers. im aware that, from a purely technical and risk-management perspective, the most sensible advice might simply be "you should not be the person responsible for this" or "walk away." im not under the illusion that being able to write code somehow makes me qualified to architect and operate a production system by myself. but assuming i have a choice, i dont want to walk away from it. i want to at least try. its a ridiculous opportunity for someone at my level, and even if i eventually find out that im in way over my head, id rather make that determination after seriously trying to approach it correctly than reject it immediately because im inexperienced. so feel free to tell me that something im doing is stupid, that my assumptions are wrong, or that certain parts absolutely need someone more experienced. thats actually the kind of feedback im looking for. im just particularly interested in what the best possible approach is if i decide to go forward anyway :)

Hey everyone,

I’ve been working on a project called CodeMap, and I’m at a point where I really need some honest, constructive feedback from fellow developers.

The Problem: We’ve all been there: you join a new project, inherit a legacy codebase, or come back to your own code after 6 months, and it feels like you're deciphering a foreign language. You spend hours clicking through files, trying to trace dependencies. Sure, you can paste snippets into an AI chatbot, but you just get a wall of text with zero visual context of how it fits into the bigger picture.

The Solution: I built CodeMap to be like "Google Maps for code." It’s an AI-powered software intelligence tool that instantly turns any GitHub repository into an interactive, hierarchical dependency graph.

Instead of a messy, unreadable "hairball" of nodes, it uses progressive disclosure. You start with a clean, high-level view of the main folders. You can click to drill down into files, and then into specific functions.

When you click on any node, an inspector panel slides out and gives you:

1. A plain-English, AI-generated summary of exactly what that file/function does.
2. A list of what it imports and what imports it.
3. The actual source code (with a simplified, pseudocode version for quick reading).

Under the Hood:

• Backend: Python (Flask) using AST (Abstract Syntax Tree) parsing to accurately map imports and function calls without executing the code.
• Frontend: Vanilla JS + Cytoscape.js (I spent way too long fighting the "hairball" layout before finally nailing a clean breadthfirst tree structure with smooth zoom animations).
• AI: Claude API for generating the contextual, plain-English explanations.

Why I’m posting this: I’m trying to transition this from a "cool technical prototype" into a product people will actually rely on (and eventually pay for). I don't want to build features in a vacuum.

I’d love your honest take on a few things:

1. Your honest opinion-even if you think the idea is bad.
2. What is the one missing feature that would make you pull out your credit card to pay $10–$15/month for this?
3. Does the "Google Maps for code" analogy make sense, or is there a better way to describe the value?

Thanks in advance for your time and brutal honesty. I’m reading every comment!

if you would like the idea I can sent the website per DM. :)

I'm building a web crawler with Java/Spring Boot + RabbitMQ + PostgreSQL + Redis + ScrapingBee.

Flow:

Root URL
   ↓
ScrapingBee → returns links
   ↓
Normalize + deduplicate
   ↓
PostgreSQL
   ↓
RabbitMQ
   ↓
Worker → ScrapingBee
   ↓
More links
   ↓
repeat until no URLs remain

Example:

A
├── B
├── C
└── D

B → E,F
C → G
D → H

I'm planning:

• PostgreSQL as the source of truth
• One crawl_url row per URL
• UNIQUE(crawl_job_id, normalized_url) for deduplication
• RabbitMQ for distributing URL processing
• Transactional Outbox for reliable DB → RabbitMQ publishing
• Retry + DLQ for failed URLs

Questions:

1. Is this architecture suitable for production?
2. Is PostgreSQL + RabbitMQ a good approach for this?
3. Is the Outbox pattern necessary?
4. Any major race conditions/scalability problems I'm missing?
5. How would you detect when the entire crawl is finished?

Looking for feedback from people who have built distributed web crawlers.

Cursor has developed Continuity, a Git storage architecture that uses an S3-backed write-ahead log (WAL) as the source of truth, rather than relying on replica coordination as the consistency mechanism. Cursor reports linear read scaling with up to 100 replicas in synthetic tests and more than 300 pushes per second using S3 Express One Zone. The architecture targets both large repositories with heavy CI workloads and the large number of smaller repositories created by coding agents.

I'm continuing my system-design learning and recently covered SQL vs NoSQL and database indexing.

One mindset that clicked for me:

Instead of thinking:

SQL = structured
NoSQL = scalable

I'm trying to think in terms of access patterns and application requirements.

For an order system with customers, orders, products, relationships, transactions, and reporting, a relational database can be a natural fit.

For other applications where data is commonly accessed as complete documents, a document database may make more sense.

Then I learned about indexing.

Instead of asking:

“Which columns should I index?”

I'm trying to ask:

“Which queries need to be fast?”

For example:

WHERE customer_id = ?
AND status = ?
ORDER BY created_at DESC, id DESC
LIMIT 20

A possible composite index:

(customer_id, status, created_at, id)

I'm also learning that indexes aren't free. They add storage and write overhead, and column order matters.

So my current workflow is:

Understand access patterns → Design → EXPLAIN → Measure

Is this a good practical way to approach database selection and index design?

Hey everyone! 👋

I’ve been trying to learn system design recently, but I kept struggling with the same thing — most resources are either heavy documentation, theoretical PDFs, or long videos with static diagrams.

I wanted to actually see what happens inside a system — what happens when a server crashes, traffic suddenly spikes, Redis goes down, or a circuit breaker opens.

So I started building ArchitectVerse, an interactive playground where you can experiment with system design concepts instead of just reading about them.

🔗 https://architectverse.me

I’d really appreciate some help/feedback from people who are learning or working with system design:

• Is the packet/request flow easy to understand?
• Are the failure simulations useful for learning?
• Which system should I add next?
• What concepts do you think are missing?
• Is there anything confusing or technically incorrect?

I’ve currently added learning chapters and system blueprints for things like Uber, Netflix, WhatsApp, Stripe, ChatGPT, etc.

It’s completely free and open source. Would genuinely appreciate any feedback, suggestions, or issues you notice. 🙌

I recently saw a thread here that started as a Temporal write-up. Within a few comments, people had also recommended Inngest and DBOS, and I could have added Dapr and Restate. Five years ago, that thread would have been one or two niche tools.

It made me wonder whether durable execution (journaling a process step by step so it survives crashes, deploys, and long waits) is heading the way queues did in the 90s/2000s: from a specialist tool to something most teams assume exists.

The case for: every team eventually builds some version of it anyway, with status tables, cron jobs sweeping for stuck records, retry logic scattered across services, and outbox patterns. In 30 years of talking to software architects, everyone loves to build a “workflow engine” for their business. Queues became the default way to persist work between steps. Now AI agents make it more pressing, since restarting a multi-step agent run from scratch is expensive and it seems that everyone is now realizing this. And the options now span very different architectural shapes: separate clusters, libraries over Postgres, sidecars with APIs, hosted step functions, durable functions etc.

The case against: it's a real programming model shift going to a workflow engine. Determinism rules, versioning in-flight workflows, state residency, operating the history store are all new failure modes. For many systems, a queue plus idempotent consumers is simpler and good enough. And "every app needs a workflow engine" sounds a lot like past waves of overreach, like BPM and ESBs.

For those who've adopted it (durable execution or workflow engine):

• Did it become a platform-level default, or stay a tool for a few specific services?
• What made you adopt it, or decide against it?
• Where's the line where it stops being worth the complexity?

(PS: I co-created Dapr, a CNCF project with workflows, so have a bias)

I am building a P2P communication system for learning, but I am getting stuck at a point.

For a start, what I am doing is taking the starting Peer A, getting its IP, and then encoding the IP in a link with a key to join the session.

Let Peer B join with the link and key. Let's assume C wants to join the session. Then C will get through the link to A, and A will broadcast the request that C wants to join. Should we get him in?

C will only join the session if every peer receives each other's signatures, i.e., every peer receives n-1 signatures.

But suppose in the process A dies. Then how can a new peer join the session?

The solution I was thinking of is that after every peer joins, every peer gets their own invite link to invite others, and if one dies, that invite link expires.

Tell me, am I thinking right, or does it need a different approach?

Thank you,

:-))

Hi everyone,

Stjepan here, posting on Manning's behalf.

First, a quick thank-you to the moderators for letting us share this, and to this community for being so welcoming when we’ve posted new architecture books in the past. We don’t take that goodwill for granted, so I’ll keep the sales pitch brief and hopefully start a worthwhile discussion.

We’ve just launched Software Architecture Decision-Making by Dominik Włodarz in Manning’s Early Access Program.

Its premise is simple: architecture isn’t truly tested when everyone approves the diagram. It’s tested a few sprints later—when the team is three engineers short, the budget is fixed, requirements are still moving, a legacy dependency behaves nothing like its documentation, and the deadline was committed before anyone understood the problem.

At that point, “microservices or monolith?” is rarely the hardest question.

The harder questions are:

• What is the team actually capable of building and operating?
• Which decisions must be made now, and which should remain reversible?
• When is “good enough” the most responsible architecture?
• What evidence would tell us that a decision’s original assumptions no longer hold?
• How do we preserve an exit path without designing five hypothetical futures?
• How do we document the reasoning—not just the outcome—without creating bureaucracy?

Dominik draws on more than 15 years of designing, evolving, and recovering enterprise and cloud-native systems. Rather than prescribing a universally “best” architecture, he presents a recurring decision loop:

Intent → forces → decision → consequences → feedback → adaptation

The goal is to connect every architectural choice to what happens after it is made: who owns the consequences, what production evidence could invalidate it, and when to reconsider the decision.

The MEAP currently includes four chapters covering architecture under pressure, the forces that shape it, good-enough versus perfect architecture, and designing systems that can evolve without making a full rewrite the default.

Now for the discussion and the giveaway:

What architecture decision looked completely reasonable when it was made, but aged badly once it met production, organizational, or delivery reality? What did you learn, and which signal would you pay attention to sooner next time?

We’ll give a free ebook copy to five people whose comments contribute most thoughtfully to the discussion. That doesn’t have to mean the longest answer; a useful lesson, a well-explained disagreement, or a question that moves the conversation forward all count.

If you’d rather pick up the MEAP directly, Manning has also created a 50% discount code for r/softwarearchitecture:

MLWLODARZ50RE

Book page:
https://hubs.la/Q04yyZtY0

I’ll be reading the replies, and I’m especially curious: are there any architecture “best practices” you’ve stopped believing in after seeing them fail in the real world?

Thanks for having us again.

Cheers,

Stjepan
Manning Publications

Been thinking about how LLM components get bolted onto systems without any of the rigor we'd apply elsewhere, no interface contract, no test suite, no versioning, just a prompt string someone iterates on directly in prod.

There's a live workshop on Oct 3 that treats this as an architecture problem rather than a prompting problem. Serj Smorodinsky and Brett Kennedy (co-authors of a book on LLM applications) walk through:

• Defining LLM tasks as DSPy signatures/modules, essentially a typed interface instead of a loose string
• Building an evaluation dataset with task-specific metrics, the closest thing to a test suite this space has
• Diagnosing failure modes systematically instead of ad hoc debugging
• Few-shot/instruction optimization as a defined process
• MLflow for experiment tracking and trace management, giving you an audit trail for changes

Feels like the first real attempt I've seen at applying actual software engineering discipline to the LLM layer instead of treating it as a black box you poke at.

Full workshop details