<p>A practical guide to payment integration for backend engineers: how card payments work, the three integration models, idempotency, webhooks, and reconciliation.</p>

A Technical Guide to Payment Gateway Integration Process

payment-gateway-integration.webp

Payment Gateway Integration: Process, Models, Best Practices

<p>Shopify app development is the process of building a public or custom app for a single store that extends a Shopify store's functionality through Shopify's APIs.</p>

Shopify App Development: Types, Development Process & Cost

shopify-app-development.webp

The Practical Guide to Custom Shopify App Development

<p>Social media app development is the full process of building and maintaining an app where users create profiles, share content, and interact with each other.</p>

Social Media App Development: Process, Stack & Costs

social-media-app-development.webp

How to Build a Social Media App? Step-by-Step Process & Cost

<p>FastAPI is async and API-first, best for high-concurrency APIs and ML services; Flask is minimal and synchronous, best for simple web apps and prototypes.</p>

FastAPI vs Flask: Technical Differences and Use Cases

fastapi-vs-flask.webp

FastAPI vs Flask: How to Choose the Right Python Framework?

<p>Payroll software development is the process of building a system that calculates employee pay, manages taxes and deductions, processes payments, and records payroll.</p>

How to Build Payroll Software? Features, Process & Cost

payroll-software-development.webp

In-depth Custom Payroll Software Development Guide

<p>E-learning mobile app development is the process of developing an app that helps users learn, teach, and access educational content from smartphones or tablets.</p>

E-learning Mobile App Development: Types, Architecture & Cost

elearning-mobile-app-development.webp

A Practical Guide to E-learning Mobile App Development

<p>Start with a monolith unless scale or team structure demands more. Use microservices for independent delivery and serverless for event-driven or bursty workloads.</p>

Monolithic vs Microservices vs Serverless: How to Choose?

monolithic-vs-microservices-vs-serverless.webp

Monolithic vs Microservices vs Serverless: Which is The Best?

<p>Native apps are better for control, performance, security, and UX focus, while cross-platform apps are better when speed, cost, and one shared codebase matter more.</p>

Native vs Cross-Platform App: Which Approach is Better?

native-vs-cross-platform.webp

Native vs Cross-Platform App Development: Key Differences

<p>HR software development means designing, building, and integrating systems that manage the full employee lifecycle &nbsp;like hiring, records, payroll, performance, etc.</p>

HR software development is the process of designing, building, and integrating systems that manage employee data and HR workflows such as hiring, onboarding, payroll, performance, learning, and workforce planning. It can range from a simple HRIS to a full HRMS or HCM platform with AI features, analytics, and multi-country integrations.

What is HR software development?

A production-ready HR software MVP usually takes 4 to 9 months to build and roll out. A typical timeline includes discovery, architecture, UX design, iterative development, QA, security testing, compliance review, and phased rollout. Larger modules such as recruitment, learning, and advanced analytics are often added after the first release.

How long does it take to develop HR software?

An HRIS stores core employee records such as identity, job history, compensation, benefits, and org structure. An HRMS adds daily HR workflows such as payroll, time tracking, self-service, and performance management. An HCM adds strategic capabilities such as workforce planning, succession, learning, and advanced analytics.

What is the difference between HRIS, HRMS, and HCM?

Custom HR software development costs between $15,000 and $100,000+ in 2026, depending on scope, modules, integrations, team location, and compliance needs. A basic HRIS may cost $15,000 to $35,000, while a fuller HRMS MVP can cost $35,000 to $100,000+. Advanced systems with AI, multi-country workflows, and complex integrations can exceed $100,000.

How much does custom HR software cost in 2026?

Useful AI features in HR software include resume parsing, candidate-to-job matching, policy-answering chatbots, performance review drafting, smart document search, and workforce analytics. These features work best when they support HR teams rather than making final decisions.

Which AI features are worth building in HR software?

HR software should avoid AI-driven culture fit scoring, fully automated hiring or termination decisions, and sentiment analysis on private employee messages. These features can create bias, legal risk, and employee trust issues. AI should assist human review, not secretly judge, monitor, or decide for people.

Which AI features should be avoided in HR software?

HR software should include human review for important employment decisions, clear explanations for AI-assisted outputs, strong audit logs, data access controls, and monitoring for bias or drift. AI used in hiring, promotion, task allocation, or performance evaluation should be treated carefully because these use cases may fall under high-risk AI rules.

How can HR software stay compliant with the EU AI Act and GDPR?

A practical HR software stack includes PostgreSQL for employee records, Node.js or Python for backend services, Next.js for web, React Native or Flutter for mobile, Redis for caching, object storage for documents, and an event-driven integration layer for payroll, identity providers, ATS, LMS, and other HR tools.

What technology stack is suitable for HR software development?

Vietnam is a strong offshore option for HR software development because it offers experienced engineering talent, competitive development costs, and strong capability in modern stacks such as React, Node.js, Python, Go, and mobile development. For complex HR platforms, many companies combine a senior product or architecture lead with a Vietnam-based development team.

Should companies outsource HR software development to Vietnam?

HR Software Development Guide: Modules, Process, & Costs

HR Software Development: Types, Modules, Process, & Costs

hr-software-development-guide.webp

<p>Travel app development builds booking and navigation platforms that assist both travelers in managing trips and service providers in optimizing their operations.</p>

It is based on your project requirements. Native development is better for apps that need heavy and advanced features or deeper device features. Meanwhile, cross-platform with Flutter or React Native helps apps launch faster, reducing development costs.

Should I build a native app or a cross-platform travel app?

Some APIs include flight APIs, hotel APIs, GDS systems, maps, payments, weather, currency, notifications, analytics, CRM, and customer support tools. For example, Amadeus, Sabre, Google Maps, Stripe, PayPal, Firebase, Twilio, SendGrid, GA4, Mixpanel, Zendesk, and Intercom.

What APIs are commonly used in travel app development?

Yes, but the business model must be clear. You can start with affiliate APIs, curated listings, manual supplier confirmation, content-driven trip planning, price alerts, or niche travel tools. However, if you want to build a full booking platform, direct inventory, supplier contracts, or reliable API access will become important as the product grows.

Can I build a travel app without direct travel inventory?

Yes. AI is useful in travel apps when it supports real tasks like itinerary creation, booking parsing, review summaries, place recommendations, support answers, or personalized suggestions. It should be added only when the app has clean data, clear inputs, proper testing, and fallback options.

Is AI useful in travel app development?

Travel App Development Guide: Types, Process & Cost

travel-app-development.webp

A Complete Guide to Successful Travel App Development

<p>When <a href="https://reliasoftware.com/blog/go-for-web-development">building web services in Go</a>, reusing a single struct to handle both incoming data updates and outgoing user interface displays creates structural friction. Write operations require strict business validation and database integrity, while read operations need flat, fast, and pre-joined data for the UI. Forcing one model to do both jobs results in slow database queries, fragile code, and high maintenance overhead.</p>
<p><strong>Command Query Responsibility Segregation (CQRS)</strong> solves this data-handling conflict by splitting your application into two completely independent paths: a write-optimized model for commands, and a read-optimized model for queries.</p>
<p>This article walks you through a practical guide on implementing CQRS in Go. We will cover an framework-free folder structure, clean command and query dispatchers, and the real-world trade-offs you need to consider before adding this pattern to your architecture.</p>
<h2>How Coupling Reads and Writes Degrades Go Performance?</h2>
<p>In a recent project, I maintained a product catalog service that handled roughly 50 read requests for every single write. The domain model, a single Product struct, served both: it carried validation logic for writes, computed fields for display, and permission guards for updates.</p>
<p>Over time, query handlers accumulated read-specific joins and denormalized fields that had no place on the write side. Every change required touching the same model, the same repository layer, the same test suite.</p>
<p>The symptoms were subtle at first: slow query performance because the ORM was eager-loading associations the write path needed but reads did not. Then came the bigger problem: developers adding fields for display purposes that silently influenced write validation.</p>
<p>The model became load-bearing in two directions at once, and no amount of careful refactoring on a shared structure fixed that.&nbsp;</p>
<p>What I needed was CQRS in Go &mdash; a pattern that draws a hard boundary between the read and write models.</p>
<h2>What Is the CQRS Pattern?</h2>
<p>CQRS, or Query Responsibility Segregation, is an architectural pattern that splits data operations into two distinct models: commands that change state, and queries that read state.</p>
<p>The term comes from Bertrand Meyer's command-query separation principle, scaled up to the service level. In practice, the write side handles validation, business rules, and persistence. The read side optimizes for how data is consumed, flat, denormalized, fast. Neither side knows the other's shape.</p>
<p><strong>Commands vs. Queries: Key Differences</strong></p>
<table style="border-collapse: collapse; border-color: rgb(0, 0, 0); border-style: solid; margin-left: auto; margin-right: auto;" border="1" data-path-to-node="15">
<thead>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Dimension</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Command</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Query</strong></td>
</tr>
</thead>
<tbody>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Purpose</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Mutate state</td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Return data</td>
</tr>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Return Value</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Error or ID</td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">DTO / projection</td>
</tr>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Validation</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Domain rules</td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Input sanitization only</td>
</tr>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Model Used</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Domain entity</td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Read-optimized struct</td>
</tr>
<tr>
<td style="border-color: rgb(0, 0, 0); text-align: center;"><strong>Side Effects</strong></td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">Yes</td>
<td style="border-color: rgb(0, 0, 0); text-align: center;">None</td>
</tr>
</tbody>
</table>
<h2>Prerequisites</h2>
<p>Before implementing CQRS in Go, you should be comfortable with Go interfaces and how they enable <a href="https://reliasoftware.com/blog/practical-guide-to-dependency-injection-in-go-hands-on-implementation">dependency injection</a>, the repository pattern as a data access abstraction, and basic domain modeling, separating your entity from its persistence concern.</p>
<p>Familiarity with <a href="https://reliasoftware.com/blog/golang-struct">struct embedding</a> and clean type definitions helps when building the read DTO layer. If you can write a clean repository interface and inject it into a handler, you are ready.</p>
<h2>How to Implement CQRS in Go?</h2>
<p>The key insight when you implement CQRS in Go is that Go's interface system makes the dispatcher pattern clean without a framework.</p>
<h3>Domain Structure</h3>
<p>A folder layout that makes the separation visible forces discipline on contributors.</p>
<pre class="language-markdown"><code>internal/
  product/
    command/
      create_product.go      # command struct + handler
      update_product.go
    query/
      get_product.go         # query struct + handler
      list_products.go
    domain/
      product.go             # write-side entity
    dto/
      product_view.go        # read-side projection
    dispatcher.go</code></pre>
<p>In the code above, <code>command/</code> and <code>query/</code> are sibling packages with no import dependency between them. The <code>domain/</code> package belongs only to the command side, while <code>dto/</code> belongs to the query side. This layout makes it structurally impossible for a read handler to mutate domain state.</p>
<h3>Building the Command Side (Write Model)</h3>
<p>The command handler owns all write logic: validation, domain construction, and persistence. Here is a minimal <code>CreateProductCommand</code> with its handler.</p>
<pre class="language-go"><code>// command/create_product.go

type CreateProductCommand struct {
    Name     string
    Price    float64
    Category string
}

type CreateProductHandler struct {
    repo domain.ProductRepository
}

func NewCreateProductHandler(repo domain.ProductRepository) *CreateProductHandler {
    return &amp;CreateProductHandler{repo: repo}
}

func (h *CreateProductHandler) Handle(ctx context.Context, cmd CreateProductCommand) (string, error) {
    p, err := domain.NewProduct(cmd.Name, cmd.Price, cmd.Category)
    if err != nil {
        return "", fmt.Errorf("invalid product: %w", err)
    }
    if err := h.repo.Save(ctx, p); err != nil {
        return "", fmt.Errorf("save failed: %w", err)
    }
    return p.ID, nil
}</code></pre>
<p>In the code above, the handler receives a plain command struct without HTTP context and ORM model. <code>domain.NewProduct</code> enforces business rules like price validation and required fields, so the handler stays thin. Returning the new ID gives the caller enough to proceed without exposing the full domain entity.</p>
<h3>Building the Query Side (Read Model)&nbsp;</h3>
<p>The query handler returns a read-optimized DTO. It bypasses the domain model entirely and hits a read store or a denormalized view.</p>
<pre class="language-go"><code>// query/get_product.go

type GetProductQuery struct {
    ProductID string
}

type ProductView struct {
    ID           string
    Name         string
    Price        float64
    CategoryName string // denormalized &mdash; no join needed at read time
    InStock      bool
}

type GetProductHandler struct {
    readDB ReadDB
}

func (h *GetProductHandler) Handle(ctx context.Context, q GetProductQuery) (*ProductView, error) {
    return h.readDB.FindProductView(ctx, q.ProductID)
}</code></pre>
<p>In the code above, <code>ProductView</code> carries <code>CategoryName</code> as a denormalized string rather than a foreign key. This means the read model shapes data for the consumer, not for normalization.</p>
<p><code>ReadDB</code> is an interface pointing at whatever store is optimized for reads, whether that is a materialized view, a read replica, or a cache. The handler itself is deliberately trivial.</p>
<h3>Wiring It Together with a Clean Command/Query Dispatcher</h3>
<p>A simple dispatcher routes commands and queries to their handlers without <a href="https://reliasoftware.com/blog/reflection-in-golang">Golang reflection</a> or a heavy framework.</p>
<pre class="language-go"><code>// dispatcher.go

type CommandDispatcher struct {
    createProduct *command.CreateProductHandler
    updateProduct *command.UpdateProductHandler
}

func (d *CommandDispatcher) Dispatch(ctx context.Context, cmd any) (any, error) {
    switch c := cmd.(type) {
    case command.CreateProductCommand:
        return d.createProduct.Handle(ctx, c)
    case command.UpdateProductCommand:
        return d.updateProduct.Handle(ctx, c)
    default:
        return nil, fmt.Errorf("unknown command type: %T", cmd)
    }
}

type QueryDispatcher struct {
    getProduct  *query.GetProductHandler
    listProduct *query.ListProductsHandler
}

func (d *QueryDispatcher) Dispatch(ctx context.Context, q any) (any, error) {
    switch qr := q.(type) {
    case query.GetProductQuery:
        return d.getProduct.Handle(ctx, qr)
    case query.ListProductsQuery:
        return d.listProduct.Handle(ctx, qr)
    default:
        return nil, fmt.Errorf("unknown query type: %T", q)
    }
}</code></pre>
<p>In the code above, I use two separate dispatchers instead of one unified bus, which is intentional. Mixing command and query routing into a single dispatcher obscures the boundary I am trying to enforce.</p>
<p>The type switch is verbose but explicit; for larger handler counts, you can define a <code>CommandHandler[C, R]</code> <a href="https://reliasoftware.com/blog/generics-in-golang">generic interface in Go 1.18+</a>.</p>
<h3>Integrating Dispatchers with HTTP Handlers</h3>
<p>Here is how the dispatcher integrates with a typical HTTP layer</p>
<pre class="language-go"><code>// api/product_handler.go

func (h *ProductAPI) CreateProduct(w http.ResponseWriter, r *http.Request) {
    var req CreateProductRequest
    if err := json.NewDecoder(r.Body).Decode(&amp;req); err != nil {
        http.Error(w, "invalid request body", http.StatusBadRequest)
        return
    }

    cmd := command.CreateProductCommand{
        Name:     req.Name,
        Price:    req.Price,
        Category: req.Category,
    }

    result, err := h.commandDispatcher.Dispatch(r.Context(), cmd)
    if err != nil {
        http.Error(w, err.Error(), http.StatusUnprocessableEntity)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]string{"id": result.(string)})
}

func (h *ProductAPI) GetProduct(w http.ResponseWriter, r *http.Request) {
    productID := chi.URLParam(r, "id")

    q := query.GetProductQuery{ProductID: productID}
    result, err := h.queryDispatcher.Dispatch(r.Context(), q)
    if err != nil {
        http.Error(w, "product not found", http.StatusNotFound)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(result)
}</code></pre>
<p>The HTTP handler stays very thin because its only job is I/O translation. It simply decodes the JSON request, builds the command or query struct, dispatches it, and returns the response.</p>
<p>All actual business logic lives inside the command or query handlers, keeping the API layer completely separate. The type assertion <code>result.(string)</code> is a simple trade-off required because the dispatcher uses the flexible any type in its signature.</p>
<h2>When NOT to Use CQRS in Go?</h2>
<p>Go CQRS architecture is not free. It introduces immediate complexity because you must maintain parallel models, separate handler layers, and often entirely distinct data stores.</p>
<p>You should skip the CQRS pattern if your system meets any of the following criteria:</p>
<ul>
<li><strong>Your application is a simple CRUD service:</strong> If there is no meaningful difference between how you write data and how users read it, managing duplicate models adds zero value.</li>
<li><strong>Your team size or development velocity is constrained:</strong> Maintaining parallel read and write models creates overhead that can slow down small teams more than it helps.</li>
<li><strong>Your application handles low traffic volume: </strong>When traffic is minimal, a single optimized database query can easily handle both reads and writes without performance degradation.</li>
<li><strong>Your system cannot tolerate eventual consistency:</strong> When data propagates to the read store asynchronously, it introduces hard-to-debug lag. If your UI breaks because a user creates a product but cannot see it in their dashboard immediately, CQRS is not the right choice.</li>
</ul>
<p>&gt;&gt;&nbsp;<em>Read more: </em><em>A Detailed Guide to <a href="https://reliasoftware.com/blog/acid-properties-in-dbms">ACID Properties in DBMS with Examples</a></em></p>
<p>In my experience, CQRS earns its architectural weight only at scale such as a 50:1 read/write ratio, distinct read-caching strategies, or audit trails that require event sourcing. Below that threshold, a well-structured, single model is almost always the better call.</p>
<h2>Code Comparison: Bad Practices vs. Good Practice</h2>
<h3>Anti-pattern: Sharing Structs Between Read and Write Paths</h3>
<p>Reusing the domain entity directly as both the write model and the API response is the most common mistake when teams first encounter CQRS Golang implementation. Go</p>
<pre class="language-go"><code>// One struct doing two jobs

type Product struct {
    ID         string
    Name       string
    Price      float64
    CategoryID string        // write side needs FK for validation
    Category   *Category     // read side eager-loads this &mdash; ORM couples both paths
    CreatedBy  string        // internal audit field leaks into API response
    DeletedAt  *time.Time    // soft-delete flag has no business in a read DTO
}

// Handler returns domain entity directly &mdash; read and write coupled
func (h *Handler) GetProduct(ctx context.Context, id string) (*Product, error) {
    return h.repo.FindByID(ctx, id)
}</code></pre>
<p>In the code above, <code>Category</code> is an eager-loaded association the ORM fetches on every read, even when the caller only needs the name string. <code>DeletedAt</code> and <code>CreatedBy</code> are internal fields that now leak into every API consumer. Any change to write-side validation requirements forces a change to the struct that every read path depends on.</p>
<h3>Best Practice: Distinct Domain Models and Read Projections</h3>
<pre class="language-go"><code>// Write-side domain entity &mdash; internal, never serialized directly
type Product struct {
    id         string
    name       string
    price      float64
    categoryID string
    deletedAt  *time.Time
}

func NewProduct(name string, price float64, categoryID string) (*Product, error) {
    if price &lt;= 0 {
        return nil, errors.New("price must be positive")
    }
    return &amp;Product{
        id:         uuid.New().String(),
        name:       name,
        price:      price,
        categoryID: categoryID,
    }, nil
}

// Read-side projection &mdash; shaped for consumers, not for ORM
type ProductView struct {
    ID           string  `json:"id"`
    Name         string  `json:"name"`
    Price        float64 `json:"price"`
    CategoryName string  `json:"category_name"` // denormalized at write time
}

// Read handler hits a separate read store
func (h *GetProductHandler) Handle(ctx context.Context, q GetProductQuery) (*ProductView, error) {
    return h.readStore.FindView(ctx, q.ProductID)
}</code></pre>
<p>The <code>Product</code> domain entity uses unexported (lowercase) fields by design, making it completely impossible to serialize directly into JSON or leak into API responses.</p>
<p>The <code>ProductView</code> struct carries only the specific data fields that API consumers need. By denormalizing fields like <code>CategoryName</code> directly into the struct, the read path bypasses expensive database joins entirely.</p>
<p>The read-side packages and handlers never import the <code>domain</code> package. This strict rule ensures that the boundary between reads and writes is enforced automatically by the Go compiler, completely preventing accidental domain state mutations on the query side.</p>
<h2>Common Pitfalls to Avoid in <a href="https://reliasoftware.com/blog/how-to-build-microservices-in-golang-with-echo">Go Microservices</a></h2>
<p><strong>Over-engineering early: </strong>Do not use CQRS for low-traffic services processing only a few hundred requests a day. The complexity cost is immediate, but the performance benefits remain entirely theoretical. Only introduce CQRS when you have a measurable performance or code complexity issue.</p>
<p><strong>Ignoring UI lag:</strong> Asynchronous read stores cause data delay. The frontend must explicitly handle this stale data using loading states or optimistic UI updates. Assuming reads are always fresh creates hard-to-reproduce bugs.</p>
<p><strong>Sharing the database tables</strong>: Using the same database tables and ORM models for both sides eliminates the benefits of CQRS. The read store must use a separate materialized view, a dedicated read replica, or a cache populated by the write path.</p>
<p><strong>Premature event sourcing: </strong>CQRS and event sourcing are independent patterns. Adding event sourcing before your team understands how to rebuild projections or migrate event schemas creates massive maintenance debt.</p>
<p><em>&gt;&gt;&nbsp;Read more: Top 10 <a href="https://reliasoftware.com/blog/microservices-design-patterns">Microservices Design Patterns</a> Developers Should Know</em></p>
<h2>Conclusion</h2>
<p>CQRS is a powerful tool when the problem it solves like read/write asymmetry, model complexity, independent scaling is actually present in your system. What makes it worth adopting in Go specifically is that the language's interface system and package boundaries let you enforce the separation structurally rather than by convention alone.</p>
<p>That said, the pattern carries real costs: two models to maintain, eventual consistency to reason about, and onboarding complexity for new contributors. The goal is not to implement CQRS in Go because it is architecturally beautiful, but because a concrete problem in your service demands the boundary it creates.</p>
<p>Hope this blog can help you in your Golang technical path!</p>
<p style="text-align: right;"><em>&gt;&gt; Follow and contact&nbsp;<a href="https://reliasoftware.com/">Relia Software</a> for more information!</em></p>

<p>CQRS (Query Responsibility Segregation) is an architectural pattern that splits data operations into 2 models: commands to change state, and queries to read state.</p>

No. CQRS can use one database as long as the read and write models are separated in the code. Separate databases, such as PostgreSQL for writes and Redis or Elasticsearch for reads, are only needed when read traffic becomes too heavy for the main database.

Does CQRS require using two separate databases?

In pure CQRS, a command should only change state and return nothing except an error. In real APIs, returning the ID of a newly created resource is a practical and widely accepted compromise.

Can a Command return a value, or is that a violation of the pattern?

Use Go generics only when you have many commands and queries. For small or medium services, a simple type-switch dispatcher is easier to read, test, and debug.

Should I use Go generics to build my command and query dispatchers?

No. CQRS and Event Sourcing are separate patterns. You can use CQRS with a normal relational database and save the current state directly without storing every event.

Is CQRS useless without Event Sourcing?

You usually do not wrap the read and write sides in one transaction. CQRS accepts eventual consistency. If users must see every update instantly, a standard shared model may be a better fit.

How do I handle transaction boundaries across the read and write sides?

How to Implement CQRS in Go to Separate Reads and Writes?

A Guide to Implement CQRS in Go to Separate Reads and Writes

cqrs-golang.webp

<p>Colly, Goquery, Rod, Chromedp, Ferret, Playwright-Go, and net/http + Goquery are the 7 most popular web scraping frameworks for Golang developers in 2026.</p>

For static HTML, Colly is the fastest with built-in async support handling 40-50 pages/second. For JavaScript-rendered pages, Rod outperforms Chromedp with its decode-on-demand architecture.

Which Go web scraping framework is the fastest?

Yes. Use Rod, Chromedp, or Playwright-Go, all use the Chrome DevTools Protocol to control a real browser. Rod and Chromedp are Go-native; Playwright-Go wraps the Playwright ecosystem.

Can I scrape JavaScript-rendered pages with Go?

Yes. Colly remains actively maintained and is the most starred Go scraping library (~25K stars). It's production-ready with a stable API.

Is Colly still maintained in 2026?

Rod with the go-rod/stealth plugin is the best option to handle anti-bot detection. It patches common browser fingerprinting checks automatically. For HTTP-level evasion, combine Colly with proxy rotation and randomized headers.

Which framework handles anti-bot detection?

Absolutely. A common pattern is Colly + Goquery. Colly handles the crawling lifecycle (HTTP, rate limits, parallelism) while Goquery provides advanced DOM traversal. For sites with both static and dynamic pages, pair Colly with Rod.

Software Development