I wrote a piece arguing that AI's real architectural influence isn't through technical merit, it's through defaults. Curious what this sub thinks.

The core idea: legibility gets you considered, but only the default gets you chosen. Good documentation makes a pattern possible for an AI assistant to suggest, but system prompts, rules files, and scaffolding decide what it actually recommends when nobody is steering it.

A few points from the article:

• Docs are a ceiling, not a floor. I improved the docs for a YAML based endpoint approach. The assistant would use it when explicitly asked, but left to its own devices it still defaulted to \@RestController. Better docs raised what was possible without changing the default.
• Vintage lock in. Training data clusters around mainstream, older patterns (e.g. classic Spring conventions dominate over WebFlux or functional styles). This is vendor independent, it's a structural bias toward established architectures over current best practice.
• A self reinforcing ratchet. As AI generates more code, that code becomes training data for the next model. The set of architectures a model will volunteer narrows over time, generation by generation.

The takeaway: architectural decision making is shifting from merit based selection toward whoever controls the agent's configuration. That suggests teams should treat rules files / system prompts as first class architectural artifacts that need governance, review, and ownership, the same way we treat other architecture decisions.

Full article: https://blog.officefloor.net/2026/06/whoever-sets-default-sets-architecture.html

Do you already govern your rules files this way, or is this still adhoc on your teams?

wrote up how i anchor spec sections to code with ast-grep rules - each section maps to a structural query, agents use it to navigate, and a CI gate catches drift when the code moves out from under the spec

HTTP finally got a new method after 16 years because GET and POST wouldn't stop arguing

After 16 whole years, the IETF finally looked at our terrible API workarounds and said: "Fine, here."

Say hello to **QUERY** (RFC 10008).

It is literally the lovechild of **GET** and **POST**:

\- It has a request body like POST (so no more cramming 2,000 characters of search filters into a URL).

\- It is safe and idempotent like GET (so your CDN can actually cache it without throwing a fit).

We no longer have to live in sin by using POST for fetching data just because the search query is too big. Nature is healing.

It only took since 2010 to get a new verb. Now we just have to wait another 5 years for browsers and frameworks to actually support it.

To put that in perspective, the IETF spent 16 years debating a single word, while the AI industry spent the last 16 months pivoting from chatbots to agents, to superintelligence, and back to convincing everyone that a $400/month subscription is worth it...

Hey everyone,

I’m finishing my final year project and I’m having a bit of a debate with myself (and some AI tools) about how to classify my architecture for the jury. I want to be technically precise so I don't get roasted during the Q&A.

My setup:

. Front End : NextJs

• Core Backend: NestJS (Business logic, DB management, and orchestrating the flow).
• ML Service: A standalone Python API (FastAPI) specifically for EasyOCR.
• Integrations: Keycloak (Auth), MinIO (Storage), and Stripe (Payments).

The NestJS backend talks to the Python API via REST. I’m not using service discovery (Eureka) or a standalone Gateway; NestJS handles all the requests and coordinates with the other services.

The Dilemma:
I've been told a few different things and I'm not sure which one "sticks" best:

1. Some say it's Microservicesbecause of the independent processes and polyglot nature (Node + Python).
2. Claude (AI) suggested it might be a **"Hybrid Layered Architecture"**or a "Service-Based Application."
3. Others suggest it's more of a "Distributed Monolith" because NestJS is doing so much of the heavy lifting.

If you were a jury member, what would you expect to hear? Is "Service-Based Application" a safer bet since I don't have the full microservice "mesh" (discovery, circuit breakers, etc.)? I’d love to hear how a professional would label this setup.

Thanks for any insights!

I'm currently working on an architecture study for a large enterprise and would really appreciate feedback from architects who have built production systems with AWS Step Functions.

Context

The main use case is booking creation.

Clients call a single REST API to create a booking, but the request has to coordinate several downstream systems before the booking can finally be created in one of two different ERP systems.

A simplified flow looks something like this:

Validate the request.

Perform business and technical validations.

Retrieve reference data from multiple services.

Enrich the request with additional information.

Apply orchestration-specific business rules (routing, sequencing, conditional execution, etc.).

Call the appropriate ERP to create the booking.

Return a unified response regardless of which ERP handled the request.

Some post-booking activities may eventually become asynchronous, but the booking creation itself is a synchronous API where latency is important.

The ERP remains the owner of the booking domain and its core business rules. However, the orchestration layer inevitably contains some orchestration-specific logic because it has to coordinate multiple systems before the ERP can be called.

The discussion

One proposal is to implement the orchestration using AWS Step Functions Express, with Lambda tasks calling the downstream services.

The alternative is to build a custom orchestration service (for example Spring Boot) exposing the unified REST API and coordinating all of these calls internally.

My concern

My understanding has always been that workflow engines provide the most value when they orchestrate existing business capabilities into a larger business process.

For example:

Validate customer

Reserve inventory

Process payment

Create shipment

Send notification

Each of these is already a well-defined business capability, and the workflow coordinates them.

In our case, however, the API itself represents one business capability: Create Booking.

While there are multiple downstream calls, validations, enrichments and orchestration decisions, they all exist solely to fulfill this single business capability.

My concern is that choosing Step Functions may encourage us to decompose this capability into workflow states simply because we're using a workflow engine, rather than because those states represent reusable or independently meaningful business capabilities.

At the same time, I also recognize that there are legitimate orchestration concerns (routing, sequencing, retries, compensations, conditional paths, observability, etc.) that Step Functions is designed to solve.

So I'm trying to understand where experienced architects draw the line.

Questions

Does this sound like a good use case for Step Functions Express, or would you lean toward a custom orchestration service?

At what point does a complex synchronous API become better suited for a workflow engine rather than application code?

Have you seen Step Functions successfully used as the primary implementation behind high-throughput synchronous REST APIs?

Where do you generally draw the architectural boundary between:

a workflow engine,

an orchestration service,

and a normal application containing orchestration logic?

I'm not looking for "Step Functions is good" or "Spring Boot is better." I'm more interested in the architectural principles you use to decide where a workflow engine adds value versus where it introduces unnecessary complexity.

i'm working on multi-tenant application and i am trying to figure out whether tenants should be hosted in a shared dB(with tenant IDs) or in saperate databases.. can anybody tell me which one would be better and why? I would love insights from people who have dealt with multi-tenant architectures in prodiuction :)

I've been thinking about this while building a prototype over the last few months, and I'm curious whether others have run into the same problem.

We made source code explicit.

We extracted configuration from code.

We got infrastructure-as-code.

APIs became first-class artifacts.

But topology—the graph of which components communicate, how they communicate, retry behavior, event subscriptions, transport choices, architectural boundaries—is still mostly encoded throughout implementation.

As a result, questions like:

• What actually depends on this component?
• What breaks if these two services merge?
• Which architectural boundaries are enforced versus just documented?
• What retry policies actually exist in production?

often require reading code, configuration, deployment manifests and documentation together.

My hypothesis is that topology itself should become a first-class architectural artifact, with tooling that can validate and reason about it before deployment, much like infrastructure-as-code changed how we think about deployment.

I built an open-source prototype to explore that idea, but before discussing the implementation I'm much more interested in whether the premise resonates.

Does this match pain you've experienced, or is topology being implicit simply the right trade-off?

I'd especially appreciate perspectives from architects, staff/principal engineers, and platform teams working on larger systems.

If anyone wants to see the prototype for context:

https://github.com/itara-project/itara

i tried it with Fable 5 last night and the output wasnt Good at all, it was more like a simulation and less like a Game, Also Gemini 3.1pro just did a better job.

May be it was my prompt but i used Fable 5 for both planning and building. and it didnt come out to be what i expected.

Is this a good idea ? or Not ?

I'm an SDE-1 working as a backend engineer.

Maybe it's just me, but lately coding itself isn't that satisfying anymore. Especially with AI getting better every month. I still love building software, that's not the issue.

What I find myself obsessing over now is everything around the code. systems... networking... Distributed systems.. infrastructure... architecture. Even the business side of why certain technical decisions are made.

The problem is... none of this feels very accessible as a junior. Most of my day is implementing features. Which is expected. But I can't shake the feeling that if I keep doing only that, one year from now I'll just be a much faster coder.

If you were starting today, how would you intentionally move towards this kind of work? Not "learn X technology", but how would you shape your career? Teams? Roles? Side projects? Open source? Something else?

I know experience can't be rushed. I'm just trying to make sure I'm walking in the right direction.

Would genuinely appreciate advice from people who've already been through this.

ps: Please help this post reach more experienced people 😅

This one took a while, it's probably the longest thing I've written on this blog. I wanted to do a proper end-to-end walkthrough of cmd/compile: real package names, real data structures, diagrams for the AST and SSA CFG, and the flags you actually need (-m, -m=2, GOSSAFUNC, -S) to observe each phase yourself rather than just take my word for it.

Covers the full pipeline: lexer → parser → type checker → IR lowering → SSA construction → optimization passes (inlining, escape analysis, BCE, nil check elimination, register allocation) → architecture-specific code emission.

Hope it's useful — happy to answer questions or push back on anything that looks wrong.

What do i even call this ?

(this could be really confusing or dumb so apologies in advance)

so some months ago i built a distributed job scheduler as a learning project,

here is the break down of architecture

- client sends req to api gateway forwards to a scheduler

- there are multiple instance of these scheduler ( each of these are running on different PORT locally )

- scheduler writes to the DB

- watcher reads the DB, the schedules that are supposed to be enqueued (watcher sends it to an exchange)

- an exchance service routes the queue to fixed queue list

- a coordinator organizes the queue to worker assignment

- and worker than pull (lease based) and executes and updates the DB

whats confusing to me is that,

i wanted them to have seperate runtime (basically for each of the component have a seperate tmux session so that i dont create a mess in logging and debugging), so introduced different ports for each of the service and for each of there duplication so (7001, 70002, 7003 are just for queues lets say). The Scheduler, Watcher, and all those have separate main functions to boot each of them

and for that i coordinated these services using REST API's since they are running on differnt PORT's

the issue is, i dont understand do i say it a micro service?

what i see is that there are multiple seperate concerns and i am communication/coordinating using REST among them (could have used grpc, but leave it for now)

but then i also gets confused that for micro service definition even though i created seperate runtimes for each, these still represent the same thing. like a seperate "watcher service" is not independently deployed. Does it make sense ??

would you call it a micro service or is it just a distributed system ?

Hey everyone,

I'm building a proximity-based payments app where users can discover other users nearby in real time.

My current approach is pretty straightforward:

• Users periodically send their GPS coordinates over Socket.IO.
• The backend keeps track of online users.
• Whenever someone updates their location, I calculate the distance to every other online user and return only the nearby ones.

I was planning to use the Haversine formula, but I recently came across Vincenty's formula and started wondering if that's the right approach.

My main questions are:

• Is Haversine sufficient for a 50–100m radius?
• At what scale does comparing every user become a bottleneck?
• Do production apps use geohashes/spatial indexing first and then calculate distances?

I'm trying to keep the MVP simple while avoiding a design that won't scale. I'd love to hear how you'd approach this or how similar systems are built in production.