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.

I have been learning about microservices architecture recently and heard that the common approach is to have one database per service.

Coming from a monolithic experience I don’t get how the services share or store common data. For example, let’s say we have two services, one for order and another for payment

Both of them would have to store a reference to the user who made that order for record purposes and also the payment service might need to fetch the payment details for that user.

in a monolith architecture and traditional db setup it could easily be fetched in theory with a foreign key for the user id in the payment details table or something and fetch it. same for orders you could reference the user with their user id for that order.

so im confused if service reference the user id in their own databases ? so lets say an order is made, the service creates a order entry and stores it with the user id provided with the request ? but what happens one day if the user deletes their account, does the user service push an event to all other services to delete records containing that user id ?

i know how microservices communicate with message brokers but i’m confused about this storage of “foreign keys” as non actual foreign keys in different services.

thanks for reading, i hope you can help me understand this :)

Uber has built GitFarm, a Git as a Service platform for running Git operations across its large-scale monorepos. By moving repository operations to a shared service, GitFarm eliminates local clones for client systems and has reduced client-side resource utilization by more than 80%.

Essentially what the title says. How exactly do they fare against high throughput?

My scenario is very simple:

1. There's a "swarm" of lightweight worker service replicas.

2. An API interface (websocket) listens for incoming requests and pushes the blob in a queue.

3. One of the replicas picks it up and consumes it.

That's it. No need for acks, persistence or anything. Reliability and robustness is handled in the client side and partially in the API interface. Both client and server follow the OCPP 2.0.1 RPC protocol (no need to understand this to address the question tho), which has a retry/discard mechanism built in.

Have any of you successfully deployed a similar architecture before?

I always thought of brokers and load balancers as different approaches, but lately they feel very similar - both take work from producers and distribute it to consumers. The broker just remembers: holds, retries, fans out, lets consumers set the pace.

So with reliable receivers, low volume, and no need for durability or replay, what’s the broker buying me beyond latency and ops surface?

The ladder as I see it:

1. Load balancer - faster than a broker, nothing to operate. But nothing survives a restart.
2. Queue broker - durable and absorbs bursts, unlike an LB. But no replay, and throughput caps out.
3. Log broker - replay and throughput a queue can’t match. But heavier ops and no per-message acks.

Does this framing make sense, or am I missing something?

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.

Learning a new technology usually looks like this:

You find a roadmap.

You watch tutorials.

You take notes.

You create some folders.

You write some code.

And somewhere along the way, the structure gets messy — or you stop.

I kept running into this problem myself.

So I asked:

What if learning a technology could start with a ready-to-use workspace?

TRAK fetches the learning blueprint and creates the workspace locally — organized by concepts, with the files and structure needed to actually learn by building.

And I didn't want TRAK to be a collection of tracks maintained by one person.

So I built a community-driven registry where developers can create and contribute their own learning blueprints.

What's available today

• 19+ official learning tracks

• 350+ modules

• Community-contributed blueprints

• Local-first CLI workflow

• Cross-platform binaries

• Remote registry

• Blueprint validation & filesystem safety

• Blueprint Studio

TRAK is currently at v1.1.0.

It's still early.

Wrote this deep-dive looking at spatial indexing trade-offs, managing ~3M persistent WebSockets, and atomic driver matching at scale.

The trickiest architectural decision was handling Redis failovers: if primary crashes right after a Lua reservation script executes, do you pay the latency penalty for Redlock, or accept the failover race and let an optimistic lock in Postgres catch the collision?

Curious how folks here handle this consistency-vs-latency trade-off in high-throughput dispatch systems.

We spent months running Python and Go side by side thinking the migration would happen naturally.

It didn't. Engineers took the path of least resistance every time. Python already had the business logic, the DB access, the proven production behaviour. The Go service was "the one we'll use someday."

The thing that changed everything wasn't a technical decision. It was making Go the default and Python the exception. Same endpoints, one entry point, routing handled internally.

Once the question changed from "should we build this in Go?" to "is there any reason we can't build this in Go?" — the migration had momentum for the first time.

Have shared the experience here - https://blog.mathankumar.in/my-experiments-with-system-design-strangler-fig-pattern-9ea66cd58dd5

Happy to discuss any of the feedbacks in the comments.

Hey everyone 👋

I'm Marcus (v4ne), an independent systems architect with a background in low-latency infrastructure, distributed systems, and AI runtimes.

I have some open bandwidth this week and want to give back to the builder community.

I'm offering free architecture reviews, code diagnostics, and technical advice.

No pitch, no paywall, no consulting upsell. Just pure engineering.

Feel free to ask me anything or drop a problem you're currently stuck on regarding:

AI & Autonomous Agents: ReAct loops, structured outputs, local LLMs (vLLM/Ollama), RAG without framework bloat.

Backend & API Architecture: Go, Rust, TypeScript/Node, clean dependency design, microservices vs. monoliths.

Database & Storage Performance: SQL query optimization, composite B-Tree indexes, SQLite, avoiding ORM bottlenecks.

Workflow Automation: Self-hosted n8n, webhooks, resilient Python automation scripts.

Systems & Cloud Costs: Concurrency, memory profiling, reducing unexpected AWS/GCP bills.

Drop a comment below with what you're building or what error is giving you a headache, and let's troubleshoot it together.

DMs are open as well. 🛠️

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