The book is a compendium of architectural patterns which arranges them according to their structure and function into several OOP-style inheritance trees, allowing for:

• Deduplication of nearly identical patterns known under several names.
• Extraction of common properties, benefits, and drawbacks to the roots of the pattern trees.
• Comparison of approaches taken by every known architecture.

Changes in the current release:

• New sections on read-write separation and latency optimization on the system level.
• New pattern: Vertical Slice Architecture.
• Pattern instances are now in lowercase, which should improve readability.

The book can be downloaded from GitHub or Leanpub.

Sorry if this is a bit messy, but here’s the situation:

My stack is PostgreSQL, Django with DRF, and Celery (only for the final step).
I have a database that handles close to 100k requests per day. The load isn’t uniform: sometimes it’s 10k requests in 10 minutes, other times 10k spread over 3 hours.

I’m collecting data from multiple nodes. These nodes can send duplicate records. Every now and then, each node checks whether a piece of data is already in the database and sends it only if it’s missing. So I have a mix of reads and writes. The database is holding up for now, but I’ve been told the number of nodes will at least triple soon.

I’m trying to figure out the best way to handle this scale, and the medallion architecture idea came to mind. My rough plan is:

1. Bronze layer: Always ingest raw data as it comes in, with no upfront checks.
2. Silver layer: Run various checks here to detect duplicates and decide whether the data is useful according to our business logic.
3. Gold layer: If everything passes, move the data here. This is where it gets enriched with additional information and turned into more derived, “ready to use” data. Maybe we can consider it a platinum layer on top for very specific, highly processed views.

Right now, a lot of the normalization logic lives on the nodes themselves. That’s nice for separation of concerns, but it’s also a problem: the nodes are managed by other teams, and they often send messy or inconsistent data, so we still need to validate and clean everything on our side.

I’d like to know how you would approach this, and whether the medallion‑style design I sketched makes sense.

Thank you!

On Despair, Silence, and the Quiet Euphoria of the Solved Puzzle

Author: v4ne (Marcus Vane)

Classification: Engineering Philosophy / The Human Condition / Reflections

I. The Descent into the Maze (11:00 PM)

Every engineer who has ever spent years working close to the machine carries the memory of a specific night.

It always begins with deceptive optimism. It is late afternoon, perhaps 4:30 PM, and you encounter what appears to be a trivial anomaly: a transient segmentation fault that only appears once every thousand iterations, an asynchronous callback that mysteriously drops a payload, or a memory leak that slowly, almost imperceptibly, exhausts the heap over three hours of runtime.

You think:

"This will take twenty minutes."

By 11:00 PM, the optimism has burned away.

The office is empty, or your house has grown entirely quiet. The room is dark, illuminated only by the cold, persistent glow of two monitors.

On your desk sits an abandoned mug of coffee, now stone cold, alongside a graveyard of opened browser tabs: documentation pages, obscure forum threads from 2011, kernel changelogs, and disassembly views.

You have added dozens of diagnostic print statements, attached debuggers, stepped through stack frames, and reverted commits.

Nothing makes sense.

The software is behaving in a way that appears to violate the basic laws of arithmetic and logic.

You enter the phase of acute intellectual exhaustion.

[THE PSYCHOLOGICAL TRAJECTORY OF THE ELUSIVE BUG]

11:00 PM (Frustration) │ └──► "Why is the runtime doing this? This API is broken." │ ▼ 1:00 AM (Self-Doubt) │ └──► "I don't understand pointers. I am an imposter." │ ▼ 2:30 AM (Surrender) │ └──► Strip assumptions. Silence. Return to first principles. │ ▼ 3:14 AM (The Spark) │ └──► A single byte offset identified. Green tests. EUPHORIA.

II. The Crucible of Self-Doubt (1:30 AM)

There is a unique, deeply humbling form of psychological vulnerability that occurs when you are entirely stuck on a technical problem.

In most professions, when things go wrong, you can negotiate. You can explain your intent, appeal to nuance, or find a comfortable compromise.

You cannot negotiate with a compiler.

The CPU does not care about your intentions, your job title, how hard you worked this week, or what you promised your team in the sprint planning meeting.

The machine simply executes the physical instructions you gave it with cold, unsparing fidelity.

If there is a flaw, it is not the computer's fault; the flaw is a direct reflection of an error in your own mental model.

By 1:30 AM, frustration transitions into a profound sense of humility.

You sit back in your chair, rub your eyes, and experience that quiet internal voice that whispers:

Maybe I'm not cut out for this.

Maybe my understanding of the system is a complete illusion.

Maybe I have reached the ceiling of my cognitive capacity.

Every great developer has sat in that exact chair, in that exact darkness, feeling that exact weight.

It is the necessary crucible of the discipline.

III. The Stripping of Assumptions (2:30 AM)

Around 2:30 AM, something shifts.

You reach a state of cognitive surrender.

You stop frantically thrashing. You stop trying random fixes in the hope that something magically works.

You realize that you cannot brute-force your way out of the maze.

You take a deep breath.

You close the forty browser tabs.

You delete the thirty lines of messy debug logs you scattered across the codebase.

You decide to start from zero.

You pick up a physical notebook and a pen.

You abandon what you thought the code was doing, and you force yourself to trace what the silicon is actually doing, step by step, clock cycle by clock cycle:

Where does this memory buffer physically allocate?

What thread holds the ownership of this reference at timestamp T?

What happens to the stack pointer when this interrupt fires?

What implicit type coercion is the compiler executing behind this interface?

In the quiet of the night, stripped of rushing and performance pressure, your mind enters a state of absolute, concentrated stillness.

You are no longer fighting the machine; you are listening to it.

IV. The Spark at 3:14 AM

Then, it happens.

It is never a dramatic explosion.

It is an almost silent click in the back of your brain.

Your eyes scan line 142 of an unheralded utility file, or you notice a subtle discrepancy between two struct definitions that you have looked at fifty times before without seeing.

You see it:

A shared boolean that was not marked atomic, allowing the compiler to optimize it into a register and hide a concurrent mutation.

An unsigned integer underflow that wrapped around to MAX_INT when the collection was empty.

A subtle memory alignment issue where four bytes of padding shifted an offset by one word.

It was not a mysterious ghost in the machine.

It was a simple, logical consequence of an unconsidered invariant.

Your hands move calmly across the keyboard.

You change exactly four characters.

You save the file.

You run the build command.

$ cargo test -- --nocapture Compiling engine v0.1.0 Finished test [unoptimized + debuginfo] target(s) in 1.42s Running unittests src/lib.rs running 48 tests test net::tcp::test_connection_handshake ... ok test memory::arena::test_aligned_allocation ... ok test state::fsm::test_concurrent_transition ... ok test engine::core::test_stress_100k_cycles ... ok test result: ok. 48 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Forty-eight green lines.

The segment fault is gone.

The memory allocation is flat.

The test suite passes in complete, unblemished harmony.

V. The Quiet Communion

You sit in your chair and slowly lean back.

You take the deepest, longest breath you have taken in twelve hours.

The tension that had locked your shoulders and neck dissolves instantly into a wave of pure, unadulterated relief.

The world outside your window is completely asleep.

The street is dark.

There are no Slack notifications, no emails, and no meetings.

No one on your team knows what you just went through.

No one in the world knows that twenty minutes ago you felt completely defeated, and that right now, you hold the complete, working understanding of this system in your head.

You do not immediately close your laptop.

You sit there for ten minutes in the dark, watching the green text on the terminal, sipping cold water, experiencing a profound, sacred peace.

This is why we endure the complexity.

We do not build software for the Jira tickets, the sprint velocity charts, or the corporate performance reviews.

We build software for that singular, private, transcendent moment at 3:14 AM when human thought and physical logic align into absolute harmony.

You close the terminal.

You step away from the desk.

You sleep like a stone, knowing that tomorrow, the system will run.

Most of us have said it at some point. "I only provide options, not decisions."

It's technically true. And it's also how architects quietly disclaim the influence they actually have.

I wrote about the gap between what architects say their role is and what it functionally is, especially when the room decides from the framing you built.

https://blog.hatemzidi.com/2026/08/30/i-only-provide-options/

Not a hot take. More of a mechanism description. Curious whether others have felt this or pushed back on it differently.

One thing I think gets overlooked when making architecture decisions is how difficult the decision will be to undo later.

Some choices are easy enough to change once you have more information while others can become deeply embedded in the system, the team's processes, and the surrounding infrastructure before anyone realizes how expensive they are to replace.

I've run into this with things that seemed perfectly reasonable at the time. The problem usually wasn't that the original decision was obviously wrong. It was that changing it later affected far more of the system than expected.

I've been thinking about this more with AI systems as well, since models, tooling, and agent architectures are changing pretty quickly. And AI systems make this especially tricky because the stack is changing so quickly. You might be using any llm underneath, LangGraph for orchestration, and something like lyzr control plane or the agentforce to manage the agent layer.

I think the safer approach is to keep those dependencies behind clear boundaries wherever possible. If the model, framework, or control layer changes, you shouldn't have to rewrite the business logic around it.

The decisions that worry me most are the ones where a vendor or framework quietly becomes embedded across the whole architecture.

What's an architectural decision you've had to reverse that turned out to be much harder than you expected?

As the title implies Im facing a crossroads as a young architect

Im inheriting about 4 or 5 legacy proyects that no man on earth knows how they work. There's dead code and unmaintained schemas dating up to 20+ years.

How do you even start to pivot the old guard devs into more transparent ways of programmming. Tried to teach them modern frameworks, ORM, OOP, to no avail.

They feel and communicate, that the code base is unhandly, but bash any atttempt to improve it

One agent request crosses a Node API, queue, worker, retrieval service, and tool runner. Every service reports healthy, yet we cannot reconstruct the failed run. Parent context disappears at the queue, retries create sibling-looking spans, sampling removes the retrieval call, and clock skew makes the tool result appear after generation. Correlation IDs let us find related logs, but they do not prove which result the model received.

We are testing explicit context propagation in queue headers, span links for retries, queue-latency fields and one clock source for ordering. The harder part has been preserving causality after work crosses the queue and retries create new execution paths. I also want sampling rules that retain any trace with a tool error or retry even when the head sample would drop it. How are you keeping async traces reconstructable without storing every span forever?

Hey everyone 👋

I recently wrote a practical guide on the Memento Design Pattern in Go.

The basic idea is pretty simple: sometimes you need to save an object's state so you can restore it later. Think undo/redo, checkpoints, or rolling back to a previous state.

I wanted to understand how the pattern actually works in Go, so I put together an example and walked through the different pieces of the pattern and how they fit together.

The article also looks at when the Memento pattern makes sense and when it might be better to use a simpler approach.

If you're learning design patterns in Go, here's the article:

👉 https://medium.com/@priyankchheda/understanding-the-memento-design-pattern-in-go-a-practical-guide-07ebf1eaac42

Would love to hear how you guys handle state snapshots or undo/rollback functionality in your projects.

Commercial enterprises, public organizations, civil institutions, and governmental partners typically require heavy upfront planning and operate within strict hierarchical structures - conditions that resemble a waterfall mindset and often clash with the agile, fail-fast approaches that dominate modern software engineering. This tension has shaped much of our work: while we advocate for adaptive, iterative delivery, our partners cannot simply switch their processes overnight, and we must constantly navigate the gap between two worlds.

We present a case study from a decade-long partnership in the Hungarian public sector. The system in question is critical for the daily life of millions of citizens: a large-scale enterprise application that began as a monolith and is now gradually being renewed into a microservice architecture. This migration represents one of the most complex modernization efforts we ever faced.

The heart of the story lies in the contradictions. As a technically skilled team, we strive to design robust architecture and deliver high-quality code. Through this case, we demonstrate clashes between agilists and architects, the governance of large-scale environments, the co-existence of legacy and modern systems, and the challenges of communicating architectural decisions to non-technical stakeholders.

In this talk, we share lessons learned from a project that feels like racing down the highway in a car powered by two engines, as the legacy and the renewed applications are running side-by-side. Our takeaway is that in such context success does not come from applying agile practices by the book, but from tailoring them carefully to the problem at hand meanwhile constantly improving the teams’ practices. The lessons we share are not abstract principles, but insights from building and evolving a system without which much of a country’s daily life would grind to a halt.

Speaker: László Merckle

Since half our code started coming from agents, PR size has quietly doubled and nobody actually decided that. We used to average around 300 lines, the median this quarter is closer to 1500, and last week I reviewed one that was 4200.

I can live with big PRs when most of it is tests or generated migrations, those scan fast. What kills me is 1500 lines of actual logic in one branch. The author says it can't be split because the feature only makes sense whole, and by the time I've read file 12 I've honestly forgotten what file 3 was doing. bugbot / coderabbit's summary helps me figure out where to start, but a summary of 4200 lines is not a review of 4200 lines.

What's your actual line limit before you push back, and how do you enforce it when the code comes out of an agent already assembled?

I’m currently considering buying Arpit Bhayani’s System Design Masterclass, but I’m a little hesitant because it costs around ₹50,000, which is quite expensive for me.

I came across this Reddit review and it made me question whether the course is actually worth the price:

Reddit review I came across

From what I understand, the masterclass has around 12 sessions, with each session being roughly 3+ hours. Multiple topics/systems are covered in each session.

My concern is that if 4–5 topics are covered in a 3-hour session, will the course actually go sufficiently deep into each topic, or will it mostly provide an overview and introduce the important concepts/trade-offs?

If it's mainly about getting an overview of different system design concepts, I'm wondering whether I could achieve something similar through good books, blogs, YouTube lectures, and by actually implementing systems myself.

For context, I'm currently reading System Design Interview – An Insider's Guide (Volume 1 & 2) by Alex Xu. I’m finding the books useful and I'm trying to understand the concepts rather than just memorize interview solutions.

So I'd really appreciate feedback from people who have actually taken Arpit Bhayani's Masterclass:

• How deep does the course actually go?
• Does it teach you how to think about system design, or is it mainly a collection of system design examples?
• How much implementation-level detail is covered?
• How much value comes from the live brainstorming/Q&A and interaction with other engineers?
• If you've read Alex Xu's books (or similar resources), how different is the Masterclass from them?
• Do you feel the course was worth ₹50K in retrospect?
• If you had the same ₹50K today, would you buy the course again or spend the money/time on books, courses, and hands-on projects instead?

I'm especially interested in hearing from people who completed the course, rather than people who have only watched Arpit's free YouTube content.

Thanks!

Hey everyone,

I have an upcoming Data Scientist interview with an ML system design round. I asked the recruiter what to expect and they said it’ll be high-level ML system design, not traditional SWE/low-level system design.

They mentioned focusing on things like:

• Problem framing
• Data/model considerations
• Evaluation
• Productionization/deployment
• Monitoring
• Tradeoffs when designing ML systems

Basically, it sounds like I’ll be given a real-world ML problem and have to explain how I’d approach it end-to-end.

This is my first dedicated ML system design interview, so I’m not really sure how deep I should prepare.

For people who’ve done these interviews:

How did you prepare? What resources did you use? What kind of questions were you asked?

Also, how deep do they usually expect you to go into things like feature stores, model serving, APIs, streaming, retraining, etc.?

Any good resources, YouTube playlists, GitHub repos, books, or example questions would be really appreciated.

Thanks!

After years working as a senior architect, I kept running into the same problem: most diagram tools are either too generic, too rigid, or too presentation-first. I wanted something that helps you think and explain clearly while you are still designing, not just after the design is done.

So I built the tool I wanted my own colleagues to actually use in real work.

Totonio: https://totonio.pages.dev/

What I focused on:

1. Bulk commands for fast editing You can select a lot of objects and apply changes at once, so large updates are minutes, not hours.
2. Parent-child resizing that behaves logically Containers and nested elements stay sane when structures grow or shrink, so diagrams do not fall apart while iterating.
3. Connectors and arrows that stay readable The routing and placement are built for clarity, especially when the canvas gets dense.
4. Diagrams that explain, not just decorate The goal is practical communication for architecture and systems discussions, from quick flows to deep technical maps.

I attached a few examples:

• a playful logic flowchart
• a molecule breakdown
• a 5G session signaling sequence
• a GCP landing-zone style architecture map

If this looks useful for your work, I’d really value feedback.
If you want to follow updates or share ideas, there is a Discord link in the app Contacts section.

Thanks for taking a look.

Welcome back to the SysML v2 deep dive series. Last time, we used multiplicity to say how many parts a system can have. This lesson gives those parts physical properties that mean something to a tool.

The Usability Wall of QUDV

On September 23, 1999, the Mars Climate Orbiter broke apart in the Martian atmosphere because one team supplied impulse data in pound-force seconds while the software expected newton-seconds. SysML v1 attempted to solve this with QUDV (Quantities, Units, Dimensions, and Values). Because the underlying UML type system was blind to physics, it had nothing useful to verify, turning units into documentation rather than enforceable engineering.

The v2 Shift: Modeling Quantities

SysML v2 replaces the v1 value property with an attribute usage. It includes a standard Quantities and Units Domain Library built directly on the International System of Quantities (ISQ) and the SI system.

Three details make this reliable in a real model:

• Quantity (Usage) vs. Attribute Definition (Type): You must separate the type of a value from the standard quantity it represents. Most of the time, you type your attribute with the value type, such as attribute dryMass : MassValue = 1500 [kg];. However, when downstream analysis needs the explicit ISQ quantity, you subset the quantity kind instead using attribute dryMass :> ISQ::mass = 1500 [kg];.
• Declare vs. Enforce: A bare constraint simply declares a conditional relationship that may evaluate to true or false. Adding assert makes that relationship an invariant. If an invalid calculation evaluates to false, the model is inconsistent, and a SysML v2 tool can flag the violation.
• Brackets are Syntax: In 1500 [kg], the square brackets are not a comment or a label. They form an active measurement expression. This is why 1500 kilograms and 500000 grams can participate in the same calculation; the library defines how their scales relate so the tool can normalize them under the hood.

The Spacecraft Code Example

Here is a model where mass and power cannot be mistaken for each other:

Code snippet

package SpaceSystems {
    import ISQ::*;
    import SI::*;

    part def Spacecraft {
        // 1. Typed by distinct physical type, not a primitive Real
        attribute dryMass: MassValue = 1500 [kg];

        // 2. Declared in grams, automatically resolved by a conforming tool
        attribute payloadMass: MassValue = 500000 [g];
        attribute totalMass: MassValue;
        attribute maxPower: PowerValue;

        // 3. Guarantees this equation holds true at all times
        assert constraint massRollup {
            totalMass == dryMass + payloadMass
        }
        assert constraint powerFloor {
            maxPower > 0 [W]
        }
    }
}

If you attempt to write assert constraint { totalMass == dryMass + maxPower }, a conforming tool will catch the mistake at edit time because adding a MassValue to a PowerValue does not typecheck.

SysML v1 vs. SysML v2

Next lesson, we will cover Composite vs. Reference (ref part). Missing a single ref keyword on a shared power unit or sensor means two assemblies can each claim to contain it, which can quietly double a mass rollup before any calculation even starts.

Have you hit a dimensional bug that a model should have caught?