We’re a small team building an app that compares two perfumes side by side: price, reviews, specs and a short pros/cons for each.

Prices are where it falls apart. Popular perfumes are listed on plenty of local store sites with the BHD price right on the page, and we still miss them more than we should. Often it’s one-sided: same comparison, Sauvage gets a price and Bleu de Chanel gets “no confirmed price yet” (screenshot).

Current flow (Python): search for the product, pick likely store pages, fetch them, read JSON-LD / OpenGraph / microdata (plus Shopify and Woo JSON where we can), fall back to an LLM. The whole comparison gets roughly 25 seconds.

Tried: curl_cffi with Chrome impersonation (best results, and free), Playwright, patchright, crawl4ai, Firecrawl, Scrape.do, Zyte, Bright Data, and Claude with its web search tool on top. Still comes back empty way too often.

And if a user pastes the two product links or uploads photos of the bottles instead of typing names, it often just dies. Timeout, or nothing comes back.

What I suspect:

Our server is in Singapore. From my home connection here, curl_cffi alone got the price on about 8 in 10 Gulf store pages we tested. Maybe local stores treat a datacenter IP very differently (redirects, other currency, blocks)?
JS-heavy brand sites eat the whole 25 seconds, so the slower product just loses.

I've been exploring a question in software architecture:

Can we build a modular monolith today and gradually move towards microservices without rewriting our application?

I decided to build something around this idea.

Introducing Module-Switch — an open-source Java library for Spring Boot that makes it possible to switch individual application modules between local execution and independent HTTP-based deployment through configuration.

The idea is simple.

Instead of starting with distributed systems complexity, start with a well-structured modular monolith.

As the application evolves, extract modules when there's an actual architectural or operational reason to do so.

Here's what Module-Switch brings to the table:

- Selective module loading: Modules are disabled by default. Only locally enabled modules are loaded into the Spring application context.

- Interface-based communication: Modules interact through dedicated API interfaces rather than depending on each other's implementations.

- Local or remote execution: The same interface works whether a module runs inside the application or in another deployment.

- Configuration-driven extraction: Move a module into its own service by changing configuration instead of rewriting business logic.

- Architectural validation: Detect invalid module dependencies and structural violations during application startup.

- Built-in infrastructure: HTTP client generation, timeouts, retries, idempotency handling, Micrometer observations and trace-context propagation.

One architectural decision I particularly like is that the consuming module doesn't need to know whether its dependency is local or remote.

It simply depends on an interface. Module-Switch handles the rest.

I believe there's an interesting space between a traditional monolith and a distributed microservices architecture that deserves more attention.

Building this library has been a great exercise in exploring modular architecture, Spring Boot internals, dependency boundaries, HTTP communication and distributed systems trade-offs.

The project is open source and available under the Apache 2.0 license.

GitHub: https://github.com/ilyaslabs/module-switch

Technology: Java 25 | Spring Boot 4 | Spring Framework 7 | Modular Monolith | Microservices Architecture

I'd be interested in hearing how other engineers approach modular monoliths and gradual service extraction.

#Java #SpringBoot #SoftwareArchitecture #Microservices #ModularMonolith #DistributedSystems #OpenSource #BackendEngineering

So we have many microservices, I’m asking about 2: one for core logic and another for payments service. However the payments service almost always requests data from the core logic to get the dues and outstanding balances etc. And they are just 4 modules. Is it better to join the services together to eliminate the overhead of network communication? Or to keep it separate for third party integrations and any audit/compliance points? We don’t support PCI compliance, we integrate with third-party vendors. I just don’t have the experience and “a look into the future” to make this decision confidently. Of course if you need any more insight before answering I’ll be happy to answer.

For those who work in this field, do you have to code at all? I am looking to make a career shift and I’ve seen mixed suggestions on if someone wanting to join the field needs to know how to code or not.

Also, do you have a specific degree or certifications? I have a bachelor’s and master’s in business communications. My current role involves working heavily with our IT department and I believe the skills I’ve developed throughout my career could benefit in this space.

Looking for suggestions and advice. Thanks!

I recently joined a membership organisation that defines industry metrics, terminology, and reporting standards. We also collect confidential data from members to produce a broader picture of the industry.

Our members vary considerably in size and technical capability. Some are large organisations that have grown through acquisitions and have substantial internal teams. Others have only three employees.

The larger members want more standardised, API-based access to our data and industry information instead of repeatedly downloading Excel files and processing them themselves. Smaller members have not expressed a strong preference, so we would still need to accommodate less technical users.

We have limited internal software-development experience and rely on external development partners. Our existing tools are a website and a small Power BI reporting tool. Neither my team nor I have previously built and operated a production API.

Security is a major consideration: although the organisations are all members, they are also competitors, and the data they submit is confidential.

Before exposing confidential member data, I am considering a smaller, read-only API that would provide:

• Definitions of our metrics and terminology.

• Relationships between those definitions.

• Mappings between definitions used in different reporting contexts.

• Historical versions of definitions and mappings.

The complexity is not that definitions change frequently. They typically change only about once every five years. It is that similar concepts can be defined slightly differently across different areas, and those definitions need to be mapped to one another.

Those relationships are currently maintained in Excel. We also need to preserve historical changes so we can understand which definitions and mappings applied at a particular time.

The idea would be to start with reference data rather than confidential member submissions. This could give us experience designing, documenting, deploying, and maintaining an API while addressing an existing information-management problem.

An IT colleague questions whether this is worth the investment, particularly because the definitions change so infrequently. The concern is that we would spend time and money building an API with limited practical value instead of addressing the member-data use case that prompted the discussion.

I think that is a fair challenge. I do not want to justify a production service purely as a learning exercise, or assume that experience with a read-only reference-data API would prepare us for all the security requirements of a confidential-data API.

My questions are:

1. Is a reference-data API a sensible first deliverable here, or would it risk becoming a separate project that does little to advance the main goal?

2. What business value would justify it beyond learning and avoiding confidential data in the initial scope?

3. Given the low frequency of changes, would versioned JSON/CSV downloads or an existing reference-data management tool be more appropriate?

4. Which capabilities would genuinely carry over to a future member-data API, and which would still need to be designed separately?

5. With limited internal development experience, would you build this internally, work with an experienced partner, or start with a tightly scoped member-data API instead?

I am open to being told that the API is not the right starting point. I would like to understand how others would evaluate the options before we commit resources next year.

If you have any other ideas or suggestions, I am all ears!

Hey folks

I just write here to introduce "Governix" diagramming Ai agent allowing to generate architecture diagrams using a simple prompt.

Governix is a unified governance platform with Software Catalog as its core component allowing better manage the softwares, versions, software components, and contracts.

It connects to your cloud provider like aws, source controlling system like Github, roadmap and planning system like Jira and brings a connected knowledge base for any enterprise.

As part of its core functionalities it generates and updates software, architecture diagrams, health boards behind any change in software code, planning update or infrastructure deployment.

It has a free version allowing you to discover base features and operating model it provides.

Love to hear if you have any feedback, or if you end up trying it out.

Site: https://governix.io

Hope you all a great day

Which course would you recommend for learning system design thoroughly and preparing for FAANG interviews targeting 5+ years of experience? Would love to hear what worked for you

Hir/softwarearchitecture,

We are back with Lesson 24 of our technical deep dive into the SysML v2 standard.

In our previous lesson, we used perform to bind behaviors directly to physical components, replacing traditional swimlanes. However, those subsystems still couldn't send each other anything. Today, we fix that with flows and messages. We will explore how SysML v2 eliminates one of the biggest synchronization headaches in v1 by unifying data, commands, and physical items across both structural architecture and behavioral interactions.

1. The SysML v1 Fragmentation Problem

SysML v1 was actually quite strong in this area, but it suffered from heavy fragmentation. If you wanted to model movement, you used an ObjectFlow inside an activity, an ItemFlow across a connector in an Internal Block Diagram (IBD), and a Message between lifelines in a sequence diagram. Because these were three completely separate metamodel constructs, keeping your structural connections, activity data flows, and interaction scenarios consistent required manual allocations, strict modeling discipline, or custom tool validation.

2. The v2 Shift: Unification under FlowUsage

SysML v2 fixes this by unifying all three under a single foundational concept: FlowUsage (backed by a KerML Transfer).

Instead of disconnected constructs across different diagram types, SysML v2 provides three specialized forms:

• flow (Streaming Flow): Used for transfers between parts or actions. It explicitly names the source output and target input. The transfer can be ongoing while both the source and target are still operating (e.g., fuel moving from a tank to an engine).

• succession flow**:** Combines a streaming flow with temporal ordering. It asserts that the source action must complete before the transfer begins, and the transfer must complete before the target action can start.

• message**:** Used for abstract interactions (like sequence scenarios). It asserts that a transfer happens between two occurrences or events without forcing you to specify the exact port payload mechanics.

3. Sequence Diagrams as Text (Views That Cannot Drift)

Because messages and flows are unified, you can write a sequence diagram entirely in text. More importantly, a single message declaration can generate both an interconnection view and a sequence view. Your structure and your behavior can no longer disagree.

Code snippet

package CommandUplinkScenario {
    item def Command;
    item def Acknowledgement;
    item def TelemetryPacket;
    
    part def GroundStation;
    part def Spacecraft;
    
    occurrence def CommandUplink {
        ref part ground: GroundStation {
            event occurrence cmdSent;
            event occurrence ackReceived;
            event occurrence resultReceived;
        }
        ref part spacecraft: Spacecraft {
            event occurrence cmdReceived;
            event occurrence ackSent;
            event occurrence resultSent;
        }
        
        // Define the transfers (Messages)
        message ack of Acknowledgement from spacecraft.ackSent to ground.ackReceived;
        message cmd of Command from ground.cmdSent to spacecraft.cmdReceived;
        message result of TelemetryPacket from spacecraft.resultSent to ground.resultReceived;
        
        // Define the temporal sequence
        succession first cmd then ack;
        succession first ack then result;
    }
}

4. Deep Dive: Three Practical Nuances

As you start writing flows in v2, keep these three details in mind:

• send and accept**:** Flows connect structure. But when you are inside a specific behavioral action, you use the send and accept keywords to push and pull payloads directly through your structural ports (e.g., accept cmd: Command via spacecraft.cmdIn;). This creates an explicit, queryable link between your behavior and your structural interfaces.

• Sequencing is NOT flow: It is easy to mix these up. first A then B means B happens after A, but nothing actually moves (pure control). A plain flow means something moves, but adds no temporal ordering (pure data). A succession flow does both. SysML v2 strictly separates control from data.

• Where v1 Was Actually Better (Combined Fragments): Let's be honest—UML Sequence Diagrams had beautifully compact visual boxes for loops (loop), options (opt), and alternatives (alt). SysML v2 doesn't have a direct equivalent in the standard sequence view; you have to model that logic using decide and loop actions, which makes the text much more verbose. You will want to rely on an Action Flow view to visualize that logic clearly.

5. SysML v1 vs. SysML v2

Next lesson, we will cover state definitions and transitions, where a state turns out to be an action, and the exhibit keyword works exactly like perform.

For the software architects here: How do you typically keep your service-to-service message schemas synchronized with your system sequence diagrams, and how often do those diagrams drift from reality?

Need help designing a decent interview process for a tech lead / senior backend engineer. We're mainly suffering from candidate drops after/during a take-home challenge.

Fellow engineers who have been through interview processes at this level, do you mind sharing your take on take-home challenges and what's the best process you've been involved in?

hi guys so i need help in this sms otp architetcure one important point its uae first so do u guys use a provider for this or is there any other way. What are the cheap options i saw tiwilio and aws some other options all feel expensive.

help me out 😭🙏

running a multi-tenant B2B setup with pg rls & .net10 & for checking our db set up tenant-scoped is locked with SET LOCAL app.tenant_id = .... but during initial login handshake we query users and tenant_memberships to know tenant ID, so those tables cant have tenant-scoped rls applied; now, DB role has raw SELECT access across whole users table wanted to check how others lock down pre-tenant auth queries at the db layer? Do we use dedicated login? Or any lookup functions? or Just splitting schemas.

Mapping model access for three workloads right now: a service that streams interactive responses, an overnight document extraction job and an internal prototype.

A shared request boundary would make provider credentials and request-level tracing easier to own centrally. We trialed Braintrust Gateway on a subset of calls to understand that part. Retrieval and application-specific evals would stay with each service.

What's complicating the diagram is the operational mismatch. The streaming path cares about cancellation and another possible failure point. The overnight job can tolerate delayed retries and the prototype hasn't earned a hard dependency on shared infrastructure yet

Our platform team could own the gateway but application teams would still own how they handle model failures. I'm not sure a mandatory hop is the right contract for all three

Hey everyone!

I've been working on a project called Skeema, an AI-powered diagramming and system design tool.

The idea came from wanting something beyond simply generating architecture diagrams. I wanted a workspace where developers could design, explore, review, and simulate systems.

Some of the things you can do with Skeema:

• Generate system architecture diagrams from text prompts.

• Create ER, sequence, DFD, pipeline, migration, concept maps, and flowcharts.

• Review architectures and get AI-suggested improvements.

• Simulate concurrent users to identify potential bottlenecks under increasing traffic.

• Export diagrams and generate related engineering artifacts.

I'm still actively developing it, and there's plenty I'd like to improve, particularly around diagram quality and the overall design experience.

You can try it here: https://skeema.cloud

What works well? What's missing? What would make you actually use something like this in your workflow?

I'm the developer behind Skeema, so feel free to be critical. I'd like to hear honest feedback and criticism.

Thanks!

I'm the lead developer at a furniture retailer that sells in Germany, Austria, the Netherlands and Poland, where every country has its own copy of the same shop with a separate database, deploy pipeline, price lists and tax setup…

The copies were identical when they launched, but years of country-specific fixes have pulled them apart, so a checkout change now gets merged and tested 4 times and the Dutch shop is still 2 releases behind on the cart.

Our head of ecommerce wants one install where country, currency, language and tax are settings.

The platforms she's comparing for next year are Shopify Plus, Adobe Commerce and Scayle, so before that decision I'm trying to figure out which parts can be shared at all.

So if you merged country shops into a single install, what did you still have to keep separate per country?

I'm looking for some real world projects that I could explore for learning purposes, that implement patterns like layered architecture, hexagonal, onion, DDD, etc.

Appreciate any recommendations!

I am sharing Vyrulix, an open-source, offline-first desktop application designed to streamline malware triage and static analysis workflows on Windows.

The application consolidates several forensic tasks into a single interface, featuring zero-copy PE parsing via memory mapping (MapViewOfFile), structural entropy checks, Import Address Table (IAT) analysis, and Authenticode signature verification with offline revocation handling (WTD_REVOKE_WHOLECHAIN). It also includes entry-point instruction stream disassembly utilizing Capstone, tri-hash variant clustering (ImpHash, ssdeep, TLSH), and an automated 15-second disposable Windows Sandbox (.wsb) detonation module.

The project is written in Python using CustomTkinter and is structured to run locally without external cloud dependencies or telemetry. Source code and portable builds are available on GitHub for review and technical evaluation:
👉https://github.com/bakhishovism/Vyrulix

We’re finally trying to move to C4 because our current diagrams are a mess. Servers, services, and business stuff are all crammed into one picture, and nobody can read them.

We’re stuck between Structurizr and Mermaid’s C4 syntax. Structurizr is stricter and actually forces you to keep the levels separate, which we probably need. But the team already knows Mermaid from flowcharts, and all our docs use it, so Mermaid would be much less friction.

The context diagram is another thing. That one’s for product and leadership, and they’re never opening a repo. All our reviews with them happen in Miro anyway, and there’s a C4 template there.

So I’ll probably keep the context level on a Miro board and containers and components in code. Not sure if splitting it like that is going to bite us later.

how to do that? what do i need to read / do?

i been working for 2 decades in various tech roles.. the expertise i have is on .net framework and azure cloud too and only that.

i been preparing for az-305 and very close to making an attempt.

but Job descriptions dont fit what i have on my cv

any thoughts?

Cheers

I found this post by an engineer who felt coding agents had cost him his understanding of his own systems: https://turri.dev/blog/why-i-built-turri/

His answer is to make a reviewable "durable system knowledge" of what the system must do the real source of truth, regenerate the code from it, and even delete and rebuild the codebase to find gaps in the spec.

Do you think “intent as the source of truth” can work beyond small greenfield projects? Do you think this is a scalable approach when dealing with larger projects eg. above 50k lines of code?

... but I have no idea how they will come about or evolve.

Many abstractions are created to alleviate the pain of human labor. Perhaps only those type of abstractions will go away? An RDBMS is a whole capability not just an abstraction. Perhaps an abstraction will now be major hurdles rather than just "package tweaks"?