Persisting a Streaming Answer Through Stop, Retry and Concurrent Edits
Our chat-history implementation used an atomic answer claim, conditional terminal writes and conversation locks to handle Stop, Retry and concurrent edits.
Technical reviewer: Dmytro Nasyrov, Founder and CTO of Pharos Production.
Our streaming answer could reach the browser before it became a durable conversation record. Fixing that ordering was only part of the work. A second tab could start the same generation, Retry could race another Retry and a late completion could arrive after the user had deleted the answer.
When we added chat history to our medical learning platform, we treated the answer row as a state machine. The September 30 design and October 1 implementation record describe how generation ownership, terminal writes and cancellation were joined. Saving the final string was too small a contract for those interactions.
Claim the answer before starting the model
Sending a question created a complete user message and a pending assistant answer. A subscription then looked for the latest pending answer in that conversation. Reading that row did not give a subscriber ownership of it.
The generation started only after an atomic update changed the answer from PENDING to STREAMING. If another subscriber had already made the transition, the second stream ended without launching another model call. Two tabs could observe the same pending row while only one acquired the right to generate it.
This was an application invariant enforced through a conditional database update. A browser-side flag could improve the interface, but it could not establish ownership across two clients.
| Event | Stored result | Important condition |
|---|---|---|
| A subscriber claims generation | PENDING becomes STREAMING. | Only one conditional update succeeds. |
| Generation finishes successfully | Text, citations and metadata become COMPLETE. | The write precedes the terminal event. |
| The reader stops or disconnects | Partial text becomes FAILED without an error code. | Cancellation propagates to the model call. |
| The upstream stream ends without its terminal result | Partial text becomes FAILED with INCOMPLETE_ANSWER. | Transport exhaustion does not establish completion. |
| The answer has already been removed | The late completion changes nothing. | Terminal writes only update an existing STREAMING row. |
Make the terminal event describe committed state
On success, the backend stored the answer text, citations and associated metadata in one transaction. It sent the terminal event afterward. A client that immediately refetched the conversation could then read the completed answer.
Reversing that order would let the event announce a state that a database read could not yet see. A fast refetch could restore a pending answer over the completed text already displayed in the interface. The ordering therefore belonged to the server contract.
Every terminal write also checked that the answer was still STREAMING. Deletion, an edit or another closing operation could invalidate that condition while the provider was working. A late callback was allowed to finish its own execution without recreating the removed message.
The corresponding regression scenario inspected persistence from the subscriber handling the last event. Checking the database only after the entire test had settled would miss the ordering defect.
Cancellation has a transport delay of its own
A cold model could keep an HTTP stream open while producing no answer text. Pressing Stop in the browser did not necessarily make the backend notice the closed connection immediately.
Our implementation record says Tomcat detected that disconnect on the second write. Reducing the SSE keepalive interval from ten seconds to two reduced the observed propagation time from roughly twenty seconds to roughly four during a silent cold start.
Those figures describe the observed behavior of that setup. They are not percentile measurements or a cancellation guarantee across proxies and deployment topologies. The important diagnostic step was to separate the user action, backend disconnect detection and upstream cancellation.
A Stop operation preserved whatever text had arrived and stored a failed answer without an error code. An upstream stream that ended without its expected terminal result instead used INCOMPLETE_ANSWER. The distinction let the interface represent an intentional stop without labeling it a provider defect.
The answer claim cannot serialize every conversation edit
Generation ownership solved one race. It did not serialize commands that changed the surrounding conversation. Two concurrent Retry operations could each remove the previous answer and leave their own pending replacement.
The implementation therefore locked the conversation row for writes, including send, edit, Retry and feedback. This gave those operations a common serialization boundary. The recorded correction specifically notes that double Retry no longer left two pending answers.
The lock also made deletion races explicit. A send into a conversation deleted by another operation returned NOT_FOUND. It did not create an answer outside the conversation lifecycle.
Holding this boundary did not mean keeping a database transaction open throughout model generation. The conditional answer claim and short conversation mutations served different purposes. The model's waiting time did not need to become the lock duration for a reader's entire history.
Document what the recovery sweep assumes
A process restart can leave a row in a state no live request owns. The recorded design swept stale answers on a one-minute schedule, using a ten-minute age threshold. Stale streaming answers became failed incomplete answers; abandoned pending answers became stopped answers.
The threshold exceeded the documented legal request budget, including a cold-start first-token wait of up to 300 seconds and a seven-minute asynchronous request timeout. A test checked the relationship between the sweep threshold and that timeout.
This recovery model assumed one backend replica. It did not use a generation heartbeat or a distributed lease. Adding replicas would require another ownership and recovery analysis; the startup and age-based rules cannot simply be described as a distributed protocol.
Completion also remained a product state. The implementation recorded provider length and content-filter stops as complete answers containing the text received. Persisting such a result did not certify its completeness as an explanation or its medical accuracy. Our citation-validation case describes a separate boundary between valid markers and supported claims.
Evidence: the September 30 chat-history specification, implementation decisions recorded through October 1 and associated regression scenarios. The feature's merge and release are recorded on October 1. Cancellation times are historical engineering observations. No current deployment or distributed-recovery benchmark was run for this article.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 14
No matches
Try a different keyword, change the topic or clear filters
-
How long have you been in business?
Pharos Production has been in business since 2013, with over 13 years of experience in custom software development. During this time, we have delivered over 110 applications for 200+ clients across 28 industries, including FinTech, healthcare, crypto and e-commerce. We are rated 5/5 on Clutch based on 107 verified reviews (2026).
-
What services do you provide?
Pharos Production provides six core service categories: AI Development (LLM applications, AI agents, machine learning and computer vision), Blockchain and Web3 (smart contracts, DeFi, tokenization on Ethereum, Solana, TON and other chains), FinTech Development (payment platforms, digital banking, KYC and AML integration), Software Development (mobile apps, web platforms, database design, UI/UX), Security and QA (code audits, penetration testing, smart contract audits, manual and automated testing) and Consulting (architecture design, MVP validation, startup consulting).
-
Where is Pharos Production located?
Pharos Production is headquartered in Las Vegas, Nevada, USA (5348 Vegas Dr, Las Vegas, NV 89108), with an engineering office in Kyiv, Ukraine (44-B Eugene Konovalets Str. Suite 201, Kyiv 01133). We work with clients worldwide and provide remote collaboration across all time zones. Visit our contact page for directions and scheduling options.
-
How big is your team?
Pharos Production has a team of 90+ engineers, including software developers, blockchain specialists, QA engineers, DevOps experts, UI/UX designers, project managers and solution architects. Our founder, Dr. Dmytro Nasyrov, holds a PhD in Artificial Intelligence and leads the technical direction of all projects.
-
What types of customers do you serve?
We serve a wide range of clients, from startups and product companies to mid-sized enterprises and large institutions. Our clients include crypto exchanges, FinTech providers (like Pleenk), healthcare organizations, sportsbook operators (like Pro Gambling), e-commerce platforms and SaaS companies. Pharos Production has worked with 200+ clients across 28 industries since 2013, adapting engagement models to match each client's stage, whether it is MVP validation for a startup or enterprise-scale development for an established business.
-
How is a custom software development company different from an agency?
A custom software development company like Pharos Production assigns one dedicated engineering team that owns your product across multiple release cycles, instead of handing it off once a contract ends. Agencies more often rotate staff between clients and optimize for fast delivery over long-term product ownership.
Pharos Production keeps the same team on your codebase through 2-week sprints, so there is no re-onboarding cost each time you request a new feature.
-
How much does custom software development cost?
Custom software development costs vary based on project scope and complexity. At Pharos Production, typical project ranges are: MVP development ($10,000-$25,000), suitable for startups validating a product idea; full-fledged production ($25,000-$50,000), for established businesses scaling a proven concept; and full-cycle development ($50,000-$80,000+), for complex enterprise-grade systems. These ranges include architecture design, development, QA testing and deployment. Hourly rates range from $50 to $99 depending on role and seniority. Final pricing depends on technology stack, number of integrations and engagement model (staff augmentation, dedicated team or project outsourcing).
-
How long does it take to develop a custom software application?
Development timelines depend on scope and complexity. At Pharos Production, a typical MVP takes 2-4 months, a production-ready application takes 4-8 months and a complex enterprise system can take 8-12+ months. We use an agile methodology with 2-week sprints, delivering working increments after each sprint. Every sprint includes a retrospective, progress report and planning session for the next iteration. This approach ensures transparency and allows businesses to launch faster by prioritizing high-impact features first. Get a timeline estimate for your project.
-
What industries does Pharos Production serve?
Pharos Production serves 28 industries: FinTech, MiCA Compliance, Banking, Insurance, Crypto, Healthcare, Fitness, E-Commerce, Food & Restaurant, On-Demand, Manufacturing, Automotive, Energy, Oil & Gas, Supply Chain, Construction, Real Estate, Gaming, Streaming, Media, Telecom, Education, Aviation, Travel, Logistics, Marketing, Agriculture and Recommender Systems. Our deepest expertise is in FinTech, blockchain and healthcare, where we have delivered compliance-ready platforms (HIPAA, PCI DSS, GDPR) and high-load systems handling thousands of concurrent users. For the latest industry insights, read our guides on FinTech trends in 2026 and the Web3 technology stack.
-
Why hire a software development company instead of building in-house?
Hiring a software development company offers faster time-to-market, lower upfront costs and access to specialized expertise without long-term employment commitments. According to Deloitte's 2024 Global Outsourcing Survey, 57% of companies outsource software development to access skills they cannot hire internally.
Factor In-house team Software development company Time to assemble 3-6 months (recruiting + onboarding) 1-2 weeks Upfront cost High (salaries, benefits, equipment) Lower (project-based pricing) Specialized expertise Limited to who you can hire locally Access to 90+ engineers across blockchain, AI, FinTech Scalability Slow (each new hire takes months) Fast (scale up or down per sprint) Long-term commitment Full-time employment contracts Flexible engagement models Risk High if key engineers leave Company ensures continuity and knowledge transfer For businesses that need blockchain, AI or high-load architecture expertise, outsourcing to a specialized firm like Pharos Production reduces risk and accelerates delivery.
-
What projects does Pharos Production not take on?
Pharos Production focuses on mid-to-large custom software projects with budgets starting at $10,000. We do not take on template-based websites, WordPress theme customization or short-term contracts under one month. We also do not provide non-technical staffing (marketing, sales or design-only roles). Our strongest fit is blockchain, FinTech and healthcare projects where security, compliance and high-load architecture are critical. For smaller projects or MVPs under $10,000, we recommend exploring freelance platforms or no-code tools as a more cost-effective starting point.
-
Why does Pharos Production use agile methodology?
We use agile with 2-week sprints because it reduces the risk of building features that miss the mark. Each sprint ends with a working demo, a retrospective and a plan for the next iteration.
This means clients see progress every 14 days and can adjust priorities based on real results, not assumptions. We chose this approach after years of experience showing that rigid, fixed-scope contracts lead to scope creep, missed deadlines and products that do not match market needs by launch day.
-
When should you NOT hire a custom software development company?
Custom development is not the right choice in every situation. You should not hire a custom software company if: your problem is fully solved by an existing SaaS product (e.g. Shopify for e-commerce, Salesforce for CRM); your budget is under $10,000 and timeline is under 4 weeks; you need a simple landing page or marketing website (WordPress or Webflow is faster and cheaper); or you are still validating the idea and have not spoken to potential users yet.
In these cases, off-the-shelf tools or no-code platforms offer better ROI. Custom development makes sense when you need unique workflows, regulatory compliance, high-load architecture or competitive differentiation that packaged software cannot provide.
-
What kind of projects has Pharos Production delivered?
Here are three anonymized examples from our recent delivery history:
FinTech startup - payment platform (MVP)
Scope: mobile app + backend API with bank-grade encryption. Team: 4 engineers, 1 QA. Timeline: 10 weeks. Budget: $38,000. Result: launched on schedule, processed $2M+ in transactions within the first quarter.Healthcare provider - patient portal (Full product)
Scope: HIPAA-aligned web platform with EHR integration, appointment scheduling and telemedicine. Team: 6 engineers, 1 DevOps, 2 QA. Timeline: 6 months. Budget: $120,000. Result: 15,000+ active patients, zero compliance violations in two annual audits.Crypto exchange - trading engine (Complex)
Scope: high-load matching engine handling 50,000+ orders per second, multi-chain wallet infrastructure on Ethereum and Solana. Team: 8 engineers, 2 QA, 1 security auditor. Timeline: 11 months. Budget: $340,000. Result: 99.97% uptime, passed three independent security audits.See more projects: NoMoreBets, Pulse, Sagas, Gambit Stream and Pleenk. For the full portfolio, visit our case studies. Learn more about the technology behind these projects in our guide to stablecoins and crypto infrastructure.
Dmytro Ihnatov is the Lead Backend Developer at Pharos Production. He documents backend architecture and research experiments from the team's work on a professional learning platform for aesthetic medicine.
